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ABSTRACT 


The  Hellenic  Navy  General  Staff  has  a  difficult  mission  which  encompasses 
several  tactical,  operational,  and  administrative  tasks.  The  most  important  operational 
task  for  the  General  Staff  is  to  prepare  the  Operational  Activity  Schedule  for  every  ship, 
subcommand,  and  command  in  the  Hellenic  Navy.  In  order  to  more  effectively  prepare 
this  schedule,  an  automated  database  system  is  required.  This  system  would  contain  all 
operational  activity  records  for  the  Hellenic  Navy  units  and  other  pertinent  information. 
Furthermore,  the  system  would  produce  ad  hoc  reports,  as  well  as  a  variety  of  other 
reports  designed  by  the  user  to  support  ship  maintenance  schedule. 

This  thesis  designs  and  implements  an  automated  database  system  that  can  be 
used  from  the  Hellenic  Navy  General  Staff.  The  methodology  followed  is  the  standard 
systems'  development  life  cycle  (SDLC).  The  requirements  for  the  system  are  obtained, 
and  the  database  and  application  are  designed  and  implemented.  Paradox  5.0  for 
Windows  is  used  for  the  database  management  system  software.  Special  issues  like 
training,  security,  conversion,  and  maintenance  are  taken  into  consideration. 

The  result  of  this  thesis  is  a  functional  application  named  "OADS"  (Operational 
Activity  Database  System)  that  will  fulfill  users'  requirements,  keeps  track  of  the 
operational  activities  of  the  Hellenic  Navy  units,  and  help  in  performing  the  desired  tasks 
accurately. 
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I.  INTRODUCTION 


A.  OBJECTIVE 

This  thesis  designs  and  implements  a  database  system  for  the  General  Staff  of  the 
Hellenic  Navy.  The  purpose  of  the  system  is  to  keep  track  of  all  the  operational  activities 
of  the  commands,  subcommands,  and  ships  in  the  Hellenic  Navy  during  a  specific  period 
of  time.  The  implementation  of  the  database  system  would  greatly  reduce  the  work  hours 
spent  on  the  preparation  of  operational  programs  that  are  instrumental  in  accomplishing 
the  principal  tasks  of  commands,  subcommands,  and  ships  in  the  Hellenic  Navy.  The 
database  design  takes  into  consideration  the  Hellenic  Navy  General  Staffs  functional 
requirements.  The  primary  function  of  the  database  system  is  to  maintain  the  records  of 
operational  activities  by  command/subcommand/ship  and  other  relevant  information. 
From  this  database,  standard  reports  are  generated  and  ad  hoc  queries  and  reports  are 
created. 


B.  BACKGROUND 

Each  year  the  General  Staff  of  the  Hellenic  Navy  prepares  the  Operational 
Activity  Schedule  for  every  ship,  subcommand,  and  command  in  the  Hellenic  Navy, 
without  taking  into  consideration  the  operational  activities  of  these  elements  in  the 
previous  year.  Nowadays,  the  Operational  Activity  Schedule  is  being  prepared  manually 
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by  an  office  in  the  General  Staff  of  the  Navy.  This  office  keeps  data  about  the 
operational  activities  of  the  ships,  subcommands,  and  commands.  Although  the  system 
works,  it  has  a  number  of  deficiencies: 

•  A  constant  stream  of  paperwork  (in  the  form  of  memos,  reports,  and  so  on)  and 
telephone  calls  is  required  to  update  the  data  in  the  files. 

•  The  system  cannot  easily  provide  answers  to  complex  operational  questions. 
For  example,  answering  the  question,  "Which  ship(s)  have  used  over  three 
torpedoes  in  the  drill  no.  26?"  would  probably  require  some  research. 

•  Senior  officers  in  the  General  Staff  of  the  Hellenic  Navy  cannot  easily  obtain 
summary  information  required  for  decision  making. 

All  the  above  entail  some  problems  in  preparing  the  Operational  Activity 
Schedule.  Many  ships,  subcommands,  and  commands  that  had  many  activities  in  the 
previous  year  are  scheduled  to  continue  having  many  activities  in  the  following  year, 
leaving  other  ships,  subcommands,  and  commands  relatively  idle  for  two  consecutive 
years.  This  situation  makes  the  personnel  of  the  busy  commands  feel  that  they  are 
unfairly  treated  by  the  General  Staff  of  the  Navy. 

The  Operational  Activity  Database  System  (OADS)  tries  to  remedy  this  situation 
by  capturing  the  operational  activities  of  all  the  ships,  subcommands,  and  commands, 
during  a  one-year  period.  Reports  are  generated  at  the  end  of  the  year  that  include  the 
total  hours  for  each  individual  ship,  subcommand,  and  command  spent  in  exercises  and 
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individual  drills,  as  well  as  the  hours  that  a  specific  ship  was  at  a  port.  Reports  also 
include  information  about  whether  a  ship  has  performed  maintenance  activities  in  a  port, 
or  if  a  ship  has  used  any  missiles  or  torpedoes  during  a  drill  time. 

The  General  Staff  of  the  Navy  will  first  analyze  the  OADS's  reports  and  then  will 
prepare  the  Operational  Activity  Schedule  for  the  activities  of  the  next  year. 


C.  METHODOLOGY 

There  are  different  methodologies  for  developing  application  systems.  The 
process  that  will  be  followed  in  this  thesis  captures  the  essence  of  most  development 
methodologies,  as  they  are  described  in  the  text  of  Kroenke  [Ref.  1].  The  fundamental 
phases  are: 

•  Definition  phase.  During  the  definition  phase,  the  tasks  are  to  form  the 
working  team,  define  the  problem,  establish  the  scope,  and  access  feasibility 
issues. 

•  Requirements  phase.  During  the  requirements  phase,  the  tasks  are  to  create  the 
user's  data  model;  determine  the  update,  display,  and  control  mechanisms;  and 
determine  the  functional  components  of  the  application.  This  is  accomplished 
by  interviewing  the  users  and  by  using  prototypes  to  help  determine  user 
requirements. 
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•  Evaluation  phase.  During  the  evaluation  phase,  the  tasks  are  to  select  the 
system's  architecture,  and  reassess  feasibility  issues. 

•  Design  phase.  During  the  design  phase,  the  tasks  are  to  develop  the  database 
design  and  the  application  design.  The  database  design  consists  of  structuring 
the  relations  and  establishing  the  relationships  among  them.  The  application 
design  deals  with  the  design  of  the  menus,  reports,  and  forms,  as  well  as  to 
specifying  update,  display,  and  control  mechanisms. 

•  Implementation  phase.  During  the  implementation  phase,  the  tasks  are  to 
construct  the  database,  build  the  application,  and  install  it. 

This  System's  Development  Life  Cycle  was  utilized  in  the  development  of  the 
Operational  Activity  Database  System  (OADS)  of  this  thesis.  The  organization  of  this 
thesis  is  identical  to  the  organization  that  was  used  in  the  development  of  a  Database 
System  for  the  Hellenic  Navy  by  Tsongas  [Ref.  2],  due  to  the  similarity  of  the  scope  of 
the  two  applications  and  the  common  limitations  of  the  infrastructure  in  the  Hellenic 
Navy  units. 


D.  CHAPTER  OUTLINE 

In  this  thesis.  Chapters  II  -  VI  have  the  same  organization  and  emphasize  the  same 
issues  as  the  thesis  of  Tsongas  [Ref.  2],  Specifically,  this  thesis  is  organized  as  follows: 
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Chapter  II  is  a  general  description  of  the  database  development  process,  as  it  is 
described  in  Kroenke  [Ref.  1].  It  reviews  database  concepts  and  describes  the  database 
development  phases.  These  phases  are  detailed  in  the  following  chapters  as  they  apply  to 
the  OADS  application. 

Chapter  III  discusses  the  requirements  analysis  for  the  application  system.  The 
operating  environment  is  studied  by  means  of  the  user's  descriptive  list  of  requirements 
for  the  system's  functionality,  data  manipulation,  and  production  of  specific  information. 
The  requirements  and  accompanying  entity-relationship  data  flow  diagrams  are  provided. 
The  chapter  concludes  with  a  description  of  the  requirements  specifications  as  they 
pertain  to  data,  hardware,  and  software  issues. 

Chapter  IV  describes  the  design  process  followed  in  developing  the  Operational 
Activity  Database  System  (OADS).  The  data  and  process  models  developed  in  the 
previous  chapters  are  transformed  into  a  relational  and  application  design,  respectively. 
The  last  section  provides  commentary  about  the  data  dictionary  and  its  benefits  to  the 
database  system  design. 

Chapter  V  is  a  discussion  of  the  final  phases  involved  in  developing  the  database 
system.  These  phases  are  the  implementation  portion  of  the  data  and  process  design,  and 
include  programming  and  planning  for  the  system's  implementation. 

Chapter  VI  deals  with  other  important  issues  in  developing  the  system,  such  as 
database  security,  personnel  training,  system  conversion,  maintenance,  and  future 
upgrades. 
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Chapter  VII  is  the  concluding  chapter.  It  provides  a  short  summary  of  the  thesis 
and  addresses  future  enhancements  to  the  system  developed.  Also  included  are  lessons 
learned  in  developing  the  system. 

Appendices  A  through  G  supplement  the  previously  described  text.  The 
appendices  are:  Data  Dictionary,  Data  Flow  Diagrams,  Relations  and  Relational  Schema, 
Business  Rules,  Application  Code,  Application  Menus,  and  Procedures  for  installing  and 
operating  OADS. 
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II.  DATABASE  DEVELOPMENT  PROCESS 


Basic  database  definitions  as  well  as  the  database  development  methodology  are 
presented  in  this  chapter.  Each  step  of  the  system's  development  methodology  is 
described  in  some  detail.  The  discussion  of  this  chapter  is  largely  based  on  the  texts  of 
Kroenke  [Ref.  1]  and  Whitten  [Ref.  3],  and  follows  the  same  organization  of  the  thesis  of 
Tsongas  [Ref.  2]. 


A.  DATABASE  DEFINITIONS 

Database  is  a  set  of  related  records.  The  term  database  has  been  used  to  refer  to 
everything  from  a  collection  of  index  cards  to  the  volumes  of  data  that  a  government 
collects  about  its  citizens.  In  the  following,  we  shall  use  this  term  with  a  specific 
meaning,  as  it  is  indicated  in  Kroenke  [Ref.  1  ]:  A  database  is  a  self-describing  collection 
of  integrated  records. 

1.  A  Database  Is  Self-Describing 

As  Kroenke  points  out  in  [Ref.  1],  a  database  contains  a  description  of  its  own 
structure,  in  addition  to  the  user's  source  data  This  description  is  called  the  data 
dictionary  (or  data  directory,  or  metadata),  and  makes  program/data  independence 
possible.  By  examining  the  database  itself,  it  is  easy  to  determine  its  structure  and  its 
components;  no  external  documentation  of  file  and  record  formats  is  needed.  In  addition 
to  that,  if  we  change  the  structure  of  the  data  in  the  database  (such  as  inserting  new  data 


7 


items  to  an  existing  record),  we  enter  only  that  change  in  the  data  dictionary.  Few,  if  any, 
programs  will  need  to  be  changed.  In  most  cases,  only  those  programs  that  process  the 
altered  data  items  must  be  changed. 

2.  A  Database  Is  a  Collection  of  Integrated  Records 

The  standard  hierarchy  of  data  is  as  follows:  Bits  are  aggregated  into  bytes  or 
characters;  characters  are  aggregated  into  fields;  fields  are  aggregated  into  records;  and 
records  are  aggregated  into  files.  Following  the  pattern  of  that  statement,  files  are 
aggregated  into  databases.  [Ref.  1 :  p.  14] 

A  database  includes  files  of  user  and  other  data.  As  mentioned  earlier,  a  database 
contains  a  description  of  itself  in  the  form  of  metadata.  In  addition,  a  database  can 
include  indexes  that  are  used  to  represent  relationships  among  the  data  and  also  to 
improve  the  performance  of  database  applications.  Finally,  the  database  often  contains 
data  about  the  applications  that  use  the  database.  The  structure  of  a  data  entry  form,  or  a 
report,  is  sometimes  part  of  the  database.  This  last  category  of  data  is  called  application 
metadata.  Thus  a  database  contains  the  four  types  of  data:  files  of  user  data,  metadata, 
indexes,  and  application  metadata  (data  about  the  applications  that  use  the  database). 
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Figure  1:  Hierarchy  of  data  elements  in  database  processing 


3.  Components  of  a  Database  Processing  System 

Figure  2  shows  the  main  components  of  a  database  system.  The  database  is 
processed  by  the  DBMS,  which  is  used  by  both  developers  and  users.  They  can  use  the 
DBMS  either  directly  or  indirectly  via  application  programs. 


Figure  2:  Components  of  a  database  system 


B.  DATABASE  DEVELOPMENT  METHODOLOGY 


The  database  development  methodology  described  here  consists  of  four  phases: 
definition,  requirements,  evaluation,  and  design.  Each  phase  includes  a  number  of  tasks, 
as  they  are  presented  in  Whitten  [Ref.  3]. 

During  the  definition  phase  the  tasks  are  to  form  the  working  team,  define  the 
problem,  establish  the  scope,  and  assess  feasibility  issues. 

During  the  requirements  phase,  the  tasks  are  to  create  the  user's  data  model,  as 
well  as  the  functional  components  of  the  application.  This  is  accomplished  by 
interviewing  the  users  and  by  using  prototypes  to  help  determine  user  requirements. 

During  the  evaluation  phase,  the  tasks  are  to  select  the  system's  architecture  and 
reassess  feasibility  issues. 

During  the  design  phase,  the  tasks  are  to  develop  the  database  design  and  the 
application  design.  The  database  design  consists  of  structuring  the  relations  and 
establishing  relationships  among  them.  The  application  design  deals  with  the  design  of 
the  menus,  reports,  and  forms. 

Dining  the  implementation  phase,  the  tasks  are  to  construct  the  database,  build  the 
application,  and  install  it. 

The  requirements,  design,  and  implementation  phases  are  detailed  in  the 
following  sections. 
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C.  REQUIREMENTS  ANALYSIS  /  SPECIFICATIONS 


The  first  step  in  application  dedvelopment  is  to  accurately  obtain  the  system's 
information  requirements  from  the  potential  users.  No  system  can  be  designed  without 
first  understanding  the  current  processes  intended  for  improvement.  After  the  system's 
definition  and  primary  analysis  phase,  where  the  general  goals  of  the  system  are 
determined,  the  requirements  phase  follows.  The  purpose  of  this  phase  is  to  determine,  as 
specifically  as  possible,  what  the  system  must  do.  Many  times,  this  is  difficult  to  be 
accomplished  because  the  users  do  not  know  what  they  really  want.  There  are  two  tasks 
in  this  phase.  The  first  task  is  to  develop  a  user's  data  model  and  the  second  task  is  to 
determine  the  functional  components  of  each  application  that  will  use  the  database. 

1.  Data  Requirements 

During  the  data  requirements  phase,  the  major  goals  are  to  build  a  data  model  that 
documents  the  "things"  that  are  going  to  be  represented  in  the  database,  determine  the 
characteristics  of  those  "things"  that  need  to  be  stored,  and  determine  the  relationships 
among  them.  The  user's  data  model  describes  the  objects  that  must  be  stored  in  the 
database,  along  with  their  structure  and  the  relationships  that  they  have  with  one  another. 
The  output  of  the  data  requirements  phase  is  a  statement  of  requirements.  This  statement 
can  take  a  variety  of  forms:  a  verbal  description,  an  entity-relationship  or  objects 
diagrams,  one  or  more  prototypes,  or  any  combination  of  the  above.  [Ref  1] 
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The  "things"  that  are  represented  in  the  database  are  referred  to  as  either  entities  or 
semantic  objects  (in  some  cases  just  objects)  depending  on  the  modeling  technique  that 
the  designer  follows.  In  this  thesis  the  entity-relationship  model  will  be  followed. 

2.  Entity  -  Relationship  Model 

An  entity  is  something  that  can  be  identified  in  the  user's  work  environment; 
something  important  to  the  users  of  the  system  that  is  to  be  built  [Ref.  1],  Entities  are 
grouped  into  entity  classes,  or  collections  of  entities  of  the  same  type.  An  entity  class  is 
the  general  form  or  description  of  a  thing,  such  as  PRODUCT,  whereas  an  instance  of  an 
entity  class  is  the  representation  of  a  particular  entity,  such  as  PRODUCT  B1234.  The 
terms  entity  and  entity  class  are  often  used  interchangeably.  There  are  usually  many 
instances  of  an  entity  in  an  entity  class.  For  example,  within  the  class  PRODUCT,  there 
are  many  instances  -  one  for  each  product  represented  in  the  database. 

Entities  have  attributes  or  properties  which  describe  the  entity's  characteristics. 
The  E-R  model  assumes  that  all  instances  of  a  given  entity  class  have  the  same  attributes. 
Entity  instances  have  names  that  identify  them.  The  identifier  of  an  entity  instance  is  one 
or  more  of  its  attributes. 

Entities  can  be  associated  with  one  another  by  using  relationships.  The  E-R 
model  contains  both  relationship  classes  and  relationship  instances.  Relationship  classes 
are  associations  among  entity  classes,  and  relationship  instances  are  associations  among 
entity  instances.  Relationships  can  have  attributes.  A  relationship  can  include  many 
entities;  the  number  of  entities  in  a  relationship  is  the  degree  of  the  relationship. 
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In  entity-relationship  diagrams,  the  entities  are  shown  in  rectangles,  and  the 
relationships  are  shown  by  the  lines  that  connect  the  entities.  The  maximum  and 
minimum  number  of  entities  that  can  participate  in  a  relationship  is  also  shown  on  the 
diagram.  The  maximum  number  of  entities  that  can  participate  in  a  relationship,  or 
maximum  cardinality,  is  usually  shown  by  using  a  crow  foot  (if  it  is  many)  or  by  a  hash 
mark  (if  it  is  one).  The  minimum  cardinality,  minimum  number  of  entities  that  can  occur 
on  one  side  of  the  relationship,  is  usually  indicated  by  a  hash  mark  (if  it  is  one)  or  an  oval 
(if  it  is  zero). 

In  Figure  3  we  can  see  an  example  of  an  E-R  diagram.  In  this  example,  ENTITY 
No  1  can  relate  to  ENTITY  No  2  with  a  minimum  of  one  instance  and  a  maximum  of 
many  instances.  ENTITY  No  2  can  relate  to  ENTITY  No  1  with  a  minimum  of  zero 
instances  and  a  maximum  of  many  instances. 


Figure  3:  Example  of  an  E-R  diagram 


After  the  data  model  has  been  developed,  the  designer  should  consider  business 
rules  that  may  restrict  processing  against  entities.  Business  rules  may  or  may  not  be 
enforced  by  the  DBMS  or  by  the  application  program.  As  Kroenke  points  out  in  [Ref.  1 : 
p.  65],  some  business  rules  are  written  in  manual  procedures  that  the  users  of  the  database 
application  are  to  follow.  At  this  point,  the  way  in  which  the  rules  are  to  be  enforced  is 
not  important.  What  is  important  is  to  document  these  rules  so  that  they  become  part  of 
the  system's  requirements. 

Databases  do  not  model  the  real  world,  although  it  is  a  common  misconception 
that  they  do.  Rather,  databases  are  models  of  the  users'  model  of  their  business  world. 
The  appropriate  criterion  for  judging  a  data  model  is  whether  the  model  fits  the  users' 
mental  conception  of  their  world. 

3.  Data  Dictionary 

A  data  dictionary  (or  project  dictionary,  as  it  is  sometimes  called)  is  a  catalog  of 
requirements  and  specifications  for  a  new  information  system.  [Ref.  3:  p.  331]  It 
provides  definitions  of  all  the  data  items  in  the  database.  During  the  definition  phase,  the 
analysts  try  to  capture  and  store  data  about  the  system,  and  specify  the  inputs  and  outputs 
that  the  system  will  generate.  These  axe  represented  with  pictorial  models  such  as  data 
flow  diagrams,  entities,  data  stores,  etc.  The  data  dictionary  expands  this  pictorial  model 
and  captures  the  detailed  requirements  for  every  input,  output,  and  data  store.  The 
suggested  approach  for  building  the  data  dictionary  should  be  in  terms  of  "what"  data  are 
captured  and  not  in  terms  of  "how"  data  are  formatted  or  presented. 
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4.  Process  Requirements 

All  application  systems  process  data  to  produce  information  and  maintain  stored 
data.  These  requirements  should  be  logically  modeled.  In  order  to  implement  processes 
as  programs,  a  process  model  is  needed.  A  process  model  is  a  picture  of  the  flow  of  data 
through  the  system  and  the  processing  that  must  be  performed  on  the  data.  These 
processes  interact  or  interface  with  one  another.  These  interactions  take  the  form  of  data 
flows  between  processes,  which  is  the  reason  that  they  are  sometimes  called  data  flow 
models.  One  of  the  most  popular  system  modeling  tools  for  capturing  process 
requirements  is  the  data  flow  diagrams  (DFDs). 

Data  flow  diagrams  are  very  different  from  flow  charts,  in  the  following  ways: 

•  Processes  on  a  DFD  can  operate  in  parallel;  several  processes  may  be  working 
simultaneously.  This  is  a  key  advantage  over  flowcharts,  which  tend  to  show 
only  sequences  of  processes. 

•  DFDs  show  the  flow  of  data  through  a  system  unlike  flowcharts  that  show 
steps  in  an  algorithm. 

•  DFDs  can  show  processes  that  have  dramatically  different  timing  while 
flowcharts  cannot. 

The  following  describes  the  basic  components  of  a  data  flow  diagram  as  they 
appear  in  Whitten  [Ref.  3].  A  sample  DFD  model  is  shown  in  Figure  4. 
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Internal  or  External  Entity 


a. 

Every  system  has  a  boundary.  This  boundary  is  defined  by  the  internal  or 
external  entities  that  provide  the  net  input  to  the  system  and  receive  the  net  output  from 
the  system.  The  entities  sometimes  are  called  sources  or  destinations,  depending  on 
whether  they  are  inputs  or  outputs,  respectively.  Names  and  titles  can  be  used  to  describe 
the  label  of  the  entities.  Entities  never  interact  directly  with  data  stores,  and  relationships 
between  entities  are  not  modeled. 

b.  Process 

The  emphasis  on  any  DFD  is  given  to  the  processes,  sometimes  called 
activities.  Processes  transform  inputs  into  outputs  and  transform  the  structure  of  data  into 
information  contained  in  the  data.  The  logic  or  the  procedure  that  a  process  uses  to 
complete  its  task  is  not  shown.  Processes  are  titled  by  using  verb-clause  form. 

c.  Data  Store 

A  data  store,  as  the  name  implies,  shows  the  logical  storage  of  the 
information.  Data  flow  from  a  data  store  represents  the  "usage"  of  data.  This  is  the  place 
where  the  data  are  stored  after  a  process,  or  from  where  they  are  retrieved  to  be 
processed. 

d.  Data  Flow 

Data  flows  represent  inputs  or  outputs  that  move  from  or  to  processes  and 
from  or  to  data  stores.  They  are  titled  by  a  noun-clause  form.  Data  transferred  together 
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must  be  shown  as  a  single  data  flow  no  matter  how  many  documents  are  physically 
involved. 

e.  Leveling  of  Data  Flow  Diagrams 

When  studying,  analyzing,  and  designing  a  system,  it  is  good  to  have  a 
generic  pictorial  outline  of  what  the  system  does  or  will  do  when  it  is  implemented.  This 
pictorial  outline,  which  is  called  "Decomposition  Diagram",  or  "hierarchy  chart",  shows 
the  top-down  functional  decomposition  or  structure  of  a  system.  Decomposition 
diagrams  also  provide  an  outline  for  drawing  the  DFDs.  Only  the  processes  are  presented 
on  decomposition  diagrams,  and  they  are  connected  to  form  a  treelike  structure.  Process 
names  conform  with  the  ones  that  are  referred  to  in  the  DFDs.  The  top  process  is  called 
the  root;  it  is  exploded  or  factored  out  to  subsystems,  functions,  or  tasks.  It  defines  the 
scope  and  boundary  of  the  system  to  be  developed. 
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Figure  4:  Sample  DFD  Model 


D.  DATABASE  DESIGN 

This  part  addresses  the  logical  database  design  and  the  application  design.  [Ref.  2] 

1.  Logical  Database  Design 

After  the  E-R  model  is  developed,  the  next  step  is  to  transform  the  entities  into  a 
relational  design.  The  relational  model  is  important  for  two  reasons.  First,  since  the 
constructs  of  the  relational  model  are  general,  it  can  be  used  to  express 
DBMS-indipendent  designs.  Second,  the  relational  model  is  the  basis  for  an  important 
category  of  DBMS  products.  Being  familiar  with  this  model  helps  implement  databases 
using  one  of  these  products.  [Ref.  1:  p.  125] 
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Relational  Model 


a. 

A  relation  is  a  two-dimensional  table.  Each  row,  or  tuple,  in  the  table 
holds  data  that  pertains  to  something  or  a  portion  of  something  in  the  user's  environment. 
Each  column,  or  attribute,  of  the  table  contains  data  regarding  an  attribute.  For  a  table  to 
be  a  relation,  it  must  meet  certain  restrictions: 

•  The  cells  of  the  table  must  be  single  valued;  neither  repeating  groups  nor  arrays 
are  allowed  as  values. 

•  All  of  the  entries  in  any  column  must  be  of  the  same  kind. 

•  Each  column  has  a  unique  name,  and  the  order  of  the  columns  in  the  table  is 
insignificant. 

•  No  two  tuples  in  a  table  may  be  identical,  and  the  order  of  the  tuples  is 
insignificant. 

Not  all  relations  are  equal.  Some  are  better  than  others.  Normalization  is  a 
process  for  converting  a  relation  that  has  certain  update  problems  to  two  or  more  relations 
that  do  not  have  these  problems.  Even  more  important,  as  Kroenke  indicates  [Ref.  1 :  p. 
125],  normalization  can  be  used  as  a  guideline  for  checking  the  desirability  and 
correctness  of  relations. 

b.  Classes  of  Relations 

Relations  can  be  classified  by  the  types  of  modification  anomalies 
(deletion  anomaly,  insertion  anomaly,  and  referential  integrity  constraint)  to  which  they 
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are  vulnerable.  These  classes  of  relations  and  the  techniques  for  preventing  anomalies  are 
called  normal  forms.  The  normal  forms  are: 

•  First  Normal  Form  (INF) 

•  Second  Normal  Form  (2NF) 

•  Third  Normal  Form  (3NF) 

•  Boyce-Codd  Normal  Form  (BCNF) 

•  Fourth  Normal  Form  (4NF) 

•  Fifth  Normal  Form  (5NF) 

•  Domain  /  Key  Normal  Form  (DK/NF) 

Each  of  the  higher  normal  forms  contains  the  lower  ones.  This  means,  for 
example,  that  a  relation  that  is  in  the  third  normal  form  is  also  in  both  first  and  second 
normal  forms.  Therefore  the  steps  in  the  normalization  process  are  progressive,  and  one 
normal  form  follows  another.  In  each  step  only  certain  anomalies  are  eliminated.  It  is 
mandatory  for  relational  database  designers  to  satisfy  the  requirements  of  all  the  normal 
forms  to  ensure  that  all  anomalies  have  been  eliminated,  although  in  practice  relations  are 
usually  normalized  to  the  Third  Normal  Form. 

2.  Application  Design 

The  design  phase  includes  the  design  of  both  the  database  and  the  application.  An 
application  is  the  collection  of  menus,  forms,  reports,  and  programs  that  provide  a  means 
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to  update,  display,  and  control  the  objects  of  the  data  model.  During  the  application 
design,  the  specific  structure  of  forms,  reports,  menus,  and  query  facilities  are  defined. 
Also,  the  logic  of  transaction  programs  is  developed.  The  application  design  will  be 
discussed  further  in  Chapter  IV. 

E.  DATABASE  IMPLEMENTATION 

The  system's  implementation  is  the  set  of  activities  following  the  logical  design, 
and  consists  of  the  production  of  a  working  system  that  accepts  inputs  from  the  user, 
processes  data,  and  produces  the  desired  outputs.  One  very  important  task  during  the 
development  of  a  software  application  is  the  development  of  the  user's  manual  and  the 
documentation  of  the  development  process. 
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III.  REQUIREMENTS  ANALYSIS  FOR  OADS 

In  this  chapter  we  present  both  the  data  and  the  process  requirements  for  the 
OADS  application.  We  describe  the  data  model  and  the  corresponding  data  flow 
diagrams  that  represent  the  data  flow  that  create,  update,  and  display  the  entities  of  the 
data  model. 

A.  DATA  REQUIREMENTS 

Data  requirements  are  captured  in  the  form  of  entities,  attributes,  and 
relationships,  and  the  associated  data  dictionary.  This  application  consists  of  ten  entities. 
They  are  shown  in  the  E-R  diagram  of  Figure  5. 

1.  Entities 

a.  Command  Entity 

A  command  has  a  Command  Name,  which  uniquely  identifies  it,  is 
commanded  by  a  Commander  Name,  who  has  a  Commander  Rank,  and  the  base  of  the 
command  is  located  in  a  Base  Location.  The  command  is  organized  into  subcommands. 

b.  Subcommand  Entity 

A  subcommand  has  a  Subcommand  Name,  which  uniquely  identifies  it,  is 
commanded  by  a  Subcommander  Name,  who  has  a  Subcommander  Rank,  and  the  base  of 
the  subcommand  is  located  in  a  Base  Location.  The  subcommand  controls  a  set  of  ships. 
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c.  Ship  Entity 

A  ship  has  a  Hull  Number,  which  uniquely  identifies  it,  and  a  Name, 
belongs  to  a  specific  Type  of  ships,  and  has  a  Number  of  personnel  in  it.  The  ship  is 
commanded  by  a  COName,  who  has  a  CO_Rank.  Every  ship  belongs  to  a  specific 
subcommand. 

d.  Port  Entity 

Each  port  has  a  Port  Number,  which  uniquely  identifies  it,  and  a  Port 
Name,  and  it  is  located  in  a  general  geographical  Location.  Each  port  may  has  Watering, 
Fueling,  and  Maintenance  Capabilities. 

e.  Exercise  Entity 

An  exercise  has  an  Exercise  Number,  which  uniquely  identifies  it ,  and  an 
Exercise  Name.  The  date  that  the  exercise  begins  is  the  Date  begins  and  the  date  that  the 
exercise  finishes  is  the  Date  ends.  Each  exercise  has  a  Geographical  Location  where  the 
exercise  took  place.  The  exercise  consists  of  a  number  of  drills. 

f  Drill  Entity 

A  drill  has  a  Drill  Number,  which  uniquely  identifies  it ,  and  it  belongs  to 
a  specific  Drill  Type.  It  is  performed  in  a  Drill  Date  at  a  specific  Time  begins,  and  it 
finishes  at  a  specific  Time  ends.  Also,  each  drill  describes  a  specific  Objective. 
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g.  Ship-Port  Entity 

Each  ship  that  has  visited  a  port  has  gone  to  that  port  at  a  Date  begins,  and 
has  remained  there  for  a  number  of  Hours.  The  ship,  while  in  port,  was  in  a  specific 
Ship's  state  (maintenance  or  readiness)  and  may  have  taken  an  Amount  of  Fuel  in  It. 

h.  Command-Exercise  Entity 

Each  exercise  was  performed  by  a  command  for  some  Hours. 

L  Subcommand-Drill  Entity 

A  subcommand  may  performed  a  drill  for  some  Hours. 

j.  Ship-Drill  Entity 

A  ship  may  participated  to  a  drill  for  some  Hours.  During  that  drill,  the 
ship  may  have  some  Torpedoes  used,  A/A  Missiles  used  or  A/S  Missiles  used.  Also,  the 
ship  may  detected  a  number  of  Submarines  detected. 

2.  Relationships 

The  E-R  diagram  contains  contains  eleven  one  to  many  relationships.  These 
relationships  and  their  cardinalities  are  shown  in  Figure  5. 
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Figure  5:  Application's  E-R  Diagram 


DATA  DICTIONARY 

The  OADS  application  data  dictionary  is  shown  in  Appendix  A.  It  describes  each 


entity,  each  attribute  in  the  entities,  the  data  type,  and  definition  of  each' attribute. 


C.  PROCESS  REQUIREMENTS 


In  this  application,  the  decomposition  diagram  and  the  data  flow  diagrams  that 
describe  the  system's  functionality  are  shown  in  Appendix  B.  The  system  has  four  levels. 
The  zero  level  is  the  overall  system  picture  named  Operational  Activity  System.  It  is 
factored  out  into  two  different  subsystems,  Update  Subsystem  and  Retrieval  Subsystem. 
The  system's  hierarchical  outline  form  is  shown  in  Figure  6. 


1.  Update  Subsystem 

This  subsystem  has  ten  processes:  Update  Command  Process,  Update 
Subcommand  Process,  Update  Ship  Process,  Update  Exercise  Process,  Update  Drill 
Process,  Update  Port  Process,  Update  Exercise  Per  Command  Process,  Update  Drill  Per 
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Subcommand  Process,  Update  Drill  Per  Ship  Process,  and  Update  Port  Per  Ship 
Process.  Each  of  these  processes  consists  of  three  subprocesses:  Addition  Process, 
Deletion  Process,  and  Modification  Process.  Update  Subsystem's  process  hierarchy  is 
shown  in  Figure  7. 


■  Update  Subsystem 

-  Update  Command  Process 

•  Command  Addition  Process 

•  Command  Deletion  Process 

•  Command  Modification  Process 

-  Update  Subcommand  Process 

•  Subcommand  Addition  Process 

•  Subcommand  Deletion  Process 

•  Subcommand  Modification  Process 

-  Update  Ship  Process 

•  Ship  Addition  Process 

•  Ship  Deletion  Process 

•  Ship  Modification  Process 
_  Update  Exercise  Process 

•  Exercise  Addition  Process 

•  Exercise  Deletion  Process 

•  Exercise  Modification  Process 

-  Update  Drill  Process 

•  Drill  Addition  Process 

•  Drill  Deletion  Process 

•  Drill  Modification  Process 

-  Update  Port  Process 

.  Port  Addition  Process 

•  Port  Deletion  Process 

.  Port  Modification  Process 

-  Update  Exercise  Per  Command  Process 

•  Exercise/Command  Addition  Process 

•  Exercise/Command  Deletion  Process 

.  Exercise/Command  Modification  Process 

-  Update  Drill  Per  Subcommand  Process 

•  Drill/Subcommand  Addition  Process 

•  Drill/Subcommand  Deletion  Process 

•  Drill/Subcommand  Modification  Process 

-  Update  Drill  Per  Ship  Process 

•  Drill/Ship  Addition  Process 

•  Drill/Ship  Deletion  Process 

•  Drill/Ship  Modification  Process 

-  Update  Port  Per  Ship  Process 

•  Port/Ship  Addition  Process 

•  Port/Ship  Deletion  Process 

•  Port/Ship  Modification  Process 


Figure  7:  Update  Subsystem 
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2. 


Retrieval  Subsystem 


The  retrieval  subsystem  has  three  processes:  Report  Retrieval  Process,  Record 
Retrieval  Process,  and  Query  Retrieval  Process.  The  Report  Retrieval  Process  consists 
of  five  subprocesses:  Process  Exercises  Per  Command,  Process  Drills  Per  Exercise, 
Process  Ships  Per  Subcommand,  Process  Drills  Per  Ship,  and  Process  Ships  Per  Port. 
The  Record  Retrieval  Process  consists  of  five  subprocesses:  Process  Drills  Per  Exercise, 
Process  Subcommands  Per  Command,  Process  Drills  Per  Ship,  Process  Activity  Hours, 
and  Process  Ships  Per  Port.  The  Query  Retrieval  Process  consists  of  four  subprocesses: 
Process  Activity  Hours  Queries,  Process  Drill  Queries,  Process  Organization  Queries, 
and  Process  Ship  Activity  Queries.  The  user  in  the  General  Staff  of  the  Hellenic  Navy 
will  be  able  to  produce  any  report  that  will  help  the  General  Staff  in  preparing  the 
operational  activity  schedule  for  commands,  subcommands,  and  ships.  Any  query  can  be 
performed  to  the  existing  data  and  the  query  results  can  be  displayed  in  the  user's  desired 
format.  Retrieval  Subsystem's  process  hierarchy  is  shown  in  Figure  8. 
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.  Retrieval  Subsystem 

-  Report  Retrieval  Process 

•  Process  Exercises  Per  Command 

•  Process  Drills  Per  Exercise 

•  Process  Ships  Per  Subcommand 

•  Process  Drills  Per  Ship 

•  Process  Ships  Per  Port 

-  Record  Retrieval  Process 

•  Process  Drills  Per  Exercise 

•  Process  Subcommands  Per  Command 

•  Process  Drills  Per  Ship 

•  Process  Activity  Hours 

•  Process  Ships  Per  Port 
_  Query  Retrieval  Process 

•  Process  Activity  Hours  Queries 

•  Process  Drill  Queries 

•  Process  Organization  Queries 

•  Process  Ship  Activity  Queries 


Figure  8:  Retrieval  Subsystem 


D.  HARDWARE  REQUIREMENTS 

The  system  being  developed  will  be  implemented  on  an  IBM  compatible  PC 
platform  found  on  many  sites  in  the  General  Staff  of  the  Hellenic  Navy.  The  minimum 
hardware  configuration  is  a  386  SX  (16  bit  architecture)  processor  running  Windows  3.1 
at  50  MHz,  with  16  Mb  of  RAM  (32  Mb  recommended)  and  540  Mb  of  hard  drive.  Also, 
a  mouse  or  other  Windows  pointing  device  is  required,  in  order  to  effectivelly  utilize  the 
capabilities  of  the  system. 
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IV.  LOGICAL  DATABASE  AND  APPLICATION  DESIGN  FOR 


OADS 

In  this  chapter  we  discuss  the  logical  database  and  application  design  for  OADS. 
In  logical  database  design,  the  E-R  model  developed  in  the  previous  chapter  is 
transformed  into  a  relational  schema  in  preparation  for  implementation  using  a  specific 
DBMS.  In  application  design,  the  data  flow  diagrams  are  used  as  a  basis  for  developing 
the  menus,  forms,  and  reports  for  OADS.  [Ref.  2] 

A.  LOGICAL  DATABASE  DESIGN 

The  ten  entities,  describing  the  user's  environment,  are  transformed  into  ten 
relations.  Relationships  are  presented  using  foreign  keys;  the  primary  keys  are 
underlined  and  the  foreign  keys  are  indicated  in  italics.  The  complete  relational  diagram 
is  shown  in  Appendix  C. 

1.  Command  Relation 

This  relation  contains  information  about  a  command.  It  is  derived  from  the 
COMMAND  entity.  Its  primary  key  is  Command  Name.  Other  attributes  are  Base 
Location,  Commander  Name,  and  Commander  Rank.  It  has  a  1:M  mandatory 
relationship  to  Subcommand  relation,  and  a  1  :M  relationship  to  the  Command-Exercise 
relation. 
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2. 


Subcommand  Relation 


This  relation  contains  information  about  a  subcommand.  It  is  derived  from  the 
SUBCOMMAND  entity.  Its  primary  key  is  Subcommand  Name.  Other  attributes  are 
Command  Name  (foreign  key),  Subcommander  Name,  Subcommander  Rank  and  Base 
Location.  The  Subcommand  relation  has  a  M:  1  relationship  with  the  Command  relation, 
a  1:M  relationship  with  the  Ship  relation,  and  a  1:M  relationship  with  the 
Subcommand-Drill  relation. 

3.  Ship  Relation 

This  relation  contains  information  about  a  ship.  It  is  derived  from  the  SHIP  entity 
and  its  primary  key  is  Hull  Number.  Other  attributes  are  Name,  Subcommand  Name 
(foreign  key).  Type,  CO_Name,  CO  Rank  and  Number  of  personnel.  It  has  a  M:1 
relationship  to  Subcommand  relation,  a  1  :M  relationship  to  Ship-Port  relation,  and  a  1  :M 
relationship  to  Ship-Drill  relation. 

4.  Exercise  Relation 

This  relation  contains  information  about  an  exercise.  It  is  derived  from  the 
EXERCISE  entity.  Its  primary  key  is  Exercise  Number.  Other  attributes  are  Exercise 
Name,  Date  begins.  Date  ends  and  Geogr.  Location.  It  has  a  1  :M  mandatory  relationship 
to  Drill  relation  and  a  1  :M  relationship  to  Command-Exercise  relation. 
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5. 


Drill  Relation 


This  relation  contains  information  about  a  drill.  It  is  derived  from  the  DRILL 
entity.  Its  primary  key  is  Drill  Number.  Other  attributes  are  Exercise  Number  (foreign 
key),  Drill  Date,  Time  begins,  Time  ends,  Drill  Type  and  Objective.  It  has  a  1:M 
relationship  to  Ship-Drill  relation,  a  M:1  relationship  to  Exercise  relation,  and  a  1:M 
relationship  to  Subcommand-Drill  relation. 

6.  Port  Relation 

This  relation  contains  information  about  a  port.  It  is  derived  from  the  PORT 
entity.  Its  primary  key  is  Port  Number.  Other  attributes  are  Port  Name,  Location, 
Watering  Capability,  Fueling  Capability  and  Maintenance  Capability.  It  has  a  1:M 
relationship  to  Ship-Port  relation. 

7.  Ship-Port  Relation 

This  relation  contains  information  about  a  ship  and  its  visit  to  a  port.  It  is  an 
intersection  relation  that  represents  the  many  to  many  relationship  between  the  SHIP  and 
PORT  entities.  Its  primary  key  is  a  composite  one  and  it  consists  of  the  attributes:  Hull 
Number,  Port  Number  and  Date  begins.  Other  attributes  in  this  relation  are  Amount  of 
Fuel  in  It.,  Hours,  and  Ship's  state.  It  has  a  M:1  relationship  to  Port  relation  and  a  M:1 
relationship  to  Ship  relation. 
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8. 


Subcommand-Drill  Relation 


This  relation  contains  information  about  a  subcommand  and  the  drills  that  the 
subcommand  has  performed.  Alternatively  one  can  say  that  this  relation  contains 
information  about  a  drill  and  the  subcommands  that  participated  in  it.  The  primary  key  of 
this  relation  is  a  composite  one  and  it  consists  of  the  attributes  Drill  Number  and 
Subcommand  Name.  Other  attribute  of  this  relation  is  Hours.  It  has  a  M:1  relationship  to 
Drill  relation  and  a  M:  1  relationship  to  Subcommand  relation. 

9.  Command-Exercise  Relation 

This  relation  contains  information  about  a  command  and  the  exercises  that  the 
command  has  performed.  Alternatively  one  can  say  that  this  relation  contains 
information  about  an  exercise  and  the  commands  that  participated  to  it.  The  primary  key 
of  this  relation  is  a  composite  one  and  it  consists  of  the  attributes  Exercise  Number  and 
Command  Name.  Other  attribute  of  this  relation  is  Hours.  It  has  a  M:  1  relationship  to 
Exercise  relation  and  a  M:1  relationship  to  Command  relation. 

10.  Ship-Drill  Relation 

This  relation  contains  information  about  a  ship  and  the  drills  that  the  ship  has 
performed.  Alternatively  one  can  say  that  this  relation  contains  information  about  a  drill 
and  the  ships  that  participated  to  it.  The  primary  key  of  this  relation  is  a  composite  one 
consisting  of  the  attributes  Drill  Number  and  Hull  Number.  Other  attributes  of  this 
relation  are  Hours,  Torpedoes  used,  A/A  Missiles  used,  A/S  Missiles  used,  and 
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Submarines  detected.  It  has  a  M:1  relationship  to  Drill  relation  and  a  M:1  relationship  to 
Ship  relation. 

B.  APPLICATION  DESIGN 

In  application  design,  the  data  flow  diagrams  developed  in  the  requirements  phase 
are  used  as  the  basis  for  designing  the  system's  menus,  forms,  queries,  and  reports.  The 
following  section  provides  a  brief  explanation  of  each. 

1.  Menus 

OADS  is  a  menu-driven  application.  The  reason  for  using  menus  is  because  they 
are  self  explanatory  and  are  therefore  easy  to  use  by  the  Hellenic  Navy  General  Staff 
users.  The  menu  structure  of  OADS  follows  closely  the  decomposition  diagram 
developed  during  process  requirements. 

2.  Forms 

Forms  are  the  user's  primary  interface  with  the  database.  They  are  used  for 
entering,  modifying,  and  displaying  data  retrieved  from  the  database.  Special  care  was 
paid  in  designing  the  forms  for  OADS.  Every  effort  was  made  in  designing  them  to  be 
easy  to  use  and  less  prone  to  errors. 

3.  Queries 

Queries  results  are  an  output  of  the  system.  The  user  can  choose  from  a 
predetermined  set  of  queries  and  the  results  can  be  sent  to  the  screen,  or  to  the  printer.  In 
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designing  of  the  set  of  queries,  every  effort  was  made  to  be  close  to  the  queries  that  are 
currently  asked. 

4.  Reports 

Reports  are  the  main  output  that  the  system  generates  for  distribution  to  a  variety 
of  users.  Reports  can  be  sent  to  the  screen,  to  a  file,  or  to  the  printer.  Similar  to 
designing  forms,  special  care  was  paid  in  designing  the  reports  for  OADS.  Every  effort 
was  made  in  designing  them  to  be  natural,  logical,  close  to  the  format  that  is  currently  in 
use  and  less  prone  to  misinterpretation. 
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V.  IMPLEMENTATION  FOR  OADS 


In  this  chapter  we  will  discuss  the  implementation  of  the  OADS  application  and 
the  construction  of  the  database,  as  well  as  the  installation  of  both  the  database  and  the 
OADS  application.  The  Paradox  5.0  database  management  system  for  windows  is 
introduced  and  used  as  the  DBMS  of  choice  for  OADS  implementation. 

As  it  is  indicated  to  Paradox  User's  Guide  [Ref.  4],  Paradox  is  a  fast,  full-featured, 
and  easy  to  use  relational  database  program  designed  to  meet  data  management  needs. 
Paradox  can  be  used  by  computer  users  with  all  levels  of  experience  from  beginning 
database  users  to  advanced  developers.  Paradox  can  be  used  either  on  a  single  computer 
(standalone)  in  the  Hellenic  Navy  General  Staff  or  on  a  Local  Area  Network  (LAN).  To 
use  Paradox  5.0  on  a  stand-alone  computer,  you  will  need  at  a  minimum: 

•  A  100%  IBM  compatible,  protected  mode  capable  80386  or  higher  personal 
computer  with  a  hard  disk  and  a  floppy  drive. 

•  6  MB  RAM  (8  MB  is  recommended.)  Performance  will  increase  with  more 
memory. 

•  At  least  20  MB  of  free  hard  disk  space. 

•  EGA  or  higher  video  monitor. 

•  Microsoft  Windows  version  3.1  or  later. 

•  Although  not  required,  a  mouse  is  strongly  recommended. 
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The  user  interface  for  Paradox  supports  multiple  windows,  pull-down  menus, 
speed  bars,  dialog  boxes,  and  other  graphical  user  interface  components.  Also,  Paradox 
provides  mouse  support.  For  instance,  you  can  change  directories  when  loading  tables  by 
pointing  and  clicking  at  a  directory  tree  with  the  mouse.  Paradox’s  Query  By  Example 
(QBE)  capability  is  one  of  the  product's  strong  features.  Complex  queries  can  be  run 
against  single  or  joined  tables,  and  query  images  can  be  saved  for  later  use.  A  variety  of 
exact  and  inexact  queries  can  be  performed,  and  there  is  support  for  wildcards,  data 
ranges,  pattern  searches,  and  logical  conditions.  Phonetic  searches  can  be  done  with 
Paradox's  "Like"  operator. 

Paradox  5.0  has  ObjectPAL,  which  is  a  high-level,  event-driven,  object-based, 
visual  programming  language.  You  can  use  ObjectPAL  to  create  a  completely 
customized  application,  one  with  entirely  new  buttons,  menus,  dialog  boxes,  prompts, 
warnings,  and  help.  ObjectPAL  is  the  user's  tool  for  creating  the  user  interface  for  a 
database  application. 


A.  DATA  IMPLEMENTATION 

In  data  implementation,  the  relations  and  their  attributes  developed  during  logical 
database  design  are  transformed  into  tables  and  data  fields,  respectively.  Table  structures 
are  created  in  Paradox  5.0  by  choosing  File/New/Table,  or  right  clicking  the  Open  Table 
Toolbar  button  and  choosing  New.  The  structure  of  the  new  empty  table,  which  matches 
the  corresponding  relation  developed  during  the  design  phase,  is  then  specified.  For  each 
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field  of  the  table,  its  name,  field  type,  and  whether  it  is  a  key  field  are  entered.  The  data 
types  supported  by  Paradox  5.0  and  their  abbreviations  are: 

•  Alpha  (A),  for  alphanumeric  fields  up  to  255  characters  in  length. 

•  Number  (N). 

•  Money  ($),  for  currency  amounts. 

•  Memo  (M),  for  a  memo  up  to  240  characters  in  table  view. 

•  Date  (D). 

•  Time  (T). 

•  Timestamp  (@),  for  both  a  date  and  time  value. 

•  Graphic  (G),  for  pictures  in  .BMP  format. 

•  Logical  (L),  for  values  representing  true  or  false. 

Once  the  definition  of  a  table  is  completed,  a  user  can  enter  values  in  the  table 
directly  or  through  a  form. 

B.  APPLICATION  IMPLEMENTATION 

In  general,  Paradox  5.0  applications  are  built  in  the  following  stages: 

•  Get  your  data  together.  Build  and  populate  tables. 
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•  Create  the  forms.  Although  you  can  write  scripts  and  store  code  in  libraries, 
the  vast  majority  of  ObjectPAL  code  is  attached  to  objects  in  forms.  The  best 
way  to  start  is  to  create  the  forms,  place  the  objects,  and  run  the  forms. 

•  Attach  ObjectPAL  code  to  the  object's  built-in  methods.  Modify  an  object's 
behavior  by  attaching  code  to  the  appropriate  built-in  method.  Built-in 
methods  execute  in  response  to  events,  so  to  select  the  appropriate  built-in 
method,  you  should  determine  what  the  object  should  do  and  when  it  should  do 
it. 

•  Test  and  refine  the  application.  Paradox  makes  it  easy  to  develop  an 
application  one  piece  at  a  time.  You  do  not  have  to  code  the  entire  application 
before  you  can  run  a  form  and  make  sure  things  are  happening  as  you  expect. 

The  above  procedure  was  followed  in  the  implementation  of  the  OADS 
application.  First,  the  tables  were  built  and  populated,  the  forms  were  created,  system's 
reports  were  produced,  and  specific  queries  were  performed.  Next,  the  menu  hierarchy 
was  built,  and  ObjectPAL  code  was  attached.  The  system  was  tested  one  form  at  a  time, 
and  system's  code  was  debugged.  After  implementation,  the  system  was  tested  as  a 
whole. 

The  next  chapter  discusses  other  issues  that  need  to  be  taken  into  consideration 
before  OADS  can  be  fully  operational. 
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VI.  OTHER  ISSUES 


This  chapter  discusses  important  issues  concerning  the  development  of  the 
"OADS"  application,  such  as  security,  training,  conversion,  maintenance,  and  future 
upgrades.  The  issues  that  this  chapter  presents  are  the  same  issues  that  have  been  covered 
in  Tsongas'  thesis  [Ref.  2],  but  customized  for  the  OADS  application. 


A.  SECURITY 

Paradox  5.0  offers  a  very  flexible  password  scheme  with  table-by-table, 
script-by-script,  and  option-by-option  password  protection.  Access  to  a  given  table  can 
be  limited  on  a  field-by-field  basis. 

OADS  users  will  have  some  access  control  authorities  depending  on  their  rank, 
their  name,  and  their  duties  in  the  General  Staff.  The  database  administrator  of  the 
General  Staff  is  responsible  for  assigning  these  duties  and  for  determining  each  user's 
access  control. 

OADS  physical  security  falls  under  the  Navy's  policy  and  procedures  that  enforce 
rules  and  activities  for  the  General  Staffs  physical  security.  Moreover,  the  General  Staff 
has  to  take  proper  measures  to  protect  the  hardware  resources  as  well  as  the  software  and 
the  applications. 
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B.  TRAINING 


One  of  the  most  important  aspects  of  the  implementation  phase  is  the  training 
plan.  The  training  plan  is  designed  to  ensure  that  every  user  of  the  system  knows  the 
system's  basic  functions  and  how  to  perform  them.  The  success  of  any  information 
system  depends  on  the  skills  of  the  operators.  In  the  OADS  system,  the  operators  are 
officers,  petty  officers,  and  sailors  who  are  familiar  with  the  operational  activities  of 
commands,  subcommands,  and  ships,  currently  run  the  system  manually;  and  who  need 
to  be  taught  how  the  new  system  operates.  The  system  itself  is  designed  to  be  friendly 
and  easy  to  use,  and  does  not  require  the  operator  to  have  any  advanced  interpersonal 
skills.  However,  matching  basic  human  characteristics  and  skills  with  a  job's 
requirements  is  essential,  especially  when  an  automated  system  is  to  replace  a  manual  old 
one. 

The  designer's  proposal  for  the  training  is  to  start  with  the  main  users  of  the 
system  and  train  them  in  the  system's  environment  as  well  as  its  functions  and  operations. 
The  main  users  of  the  system  are  defined  as  personnel  working  in  the  General  Staff 
Operational  Activity  Schedule  office.  They  are  led  by  a  Captain  whose  team  normally 
consists  of  a  Lieutenant  Commander,  two  Lieutenants,  three  Petty  Officers,  and  three 
sailors.  As  soon  as  the  trained  core  learn  how  to  operate  the  system,  training  for  the  rest 
of  the  personnel  of  the  General  Staff  can  be  held. 
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C.  CONVERSION 

The  future  success  of  the  new  system  depends  on  how  well  and  quickly  it  is 
accepted  by  the  users.  With  OADS  application,  it  is  hoped  that  the  system  is  rather  small 
and  the  users  are  already  familiar  with  the  environment;  proper  training  will  minimize 
these  problems.  Another  way  to  minimize  implementation  problems  is  to  select  the 
correct  conversion  strategy. 

1.  Conversion  Strategy 

For  the  OADS  application  conversion  strategy,  the  phased  approach  is  proposed. 
The  new  system  is  easy  to  be  implemented  as  soon  as  the  data  for  a  specific  period  of 
time  have  been  collected.  The  transition  from  the  old  system  to  the  new  one  is  expected 
to  last  two  months  at  most.  With  the  phased  conversion  approach,  the  Hellenic  Navy  will 
have  the  following  advantages: 

•  Elimination  of  risk  involved  with  implementing  the  new  system. 

•  Demands  for  extra  manpower  can  be  controlled. 

•  Shift  from  the  old  system  to  the  new  one  is  quite  smooth. 

•  User  resistance  is  minimized. 

The  period  of  three  months  is  a  reasonable  interval  for  checking  all  the  system's 
reports  and  making  the  users  familiar  with  the  OADS. 
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D.  MAINTENANCE 


Once  the  system  passes  the  acceptance  test,  it  is  ready  for  delivery.  Any 
modifications  or  enhancements  after  delivery  is  called  maintenance.  Attention  should  be 
paid  to  the  fact  that  after  a  few  years  of  operating  the  original  system,  maintenance 
becomes  extremely  tedious,  error-prone,  and  expensive.  In  this  case,  management  should 
recognize  the  problem  and  do  a  feasibility  study  on  replacing  the  old  system  with  a  new 
one. 


E.  FUTURE  ENHANCEMENTS 

The  OADS  system  design  offers  a  flexible  way  for  future  upgrades.  Paradox 
itself  can  be  distributed  on  a  network  (LAN  in  the  Hellenic  Navy  General  Staff,  or  WAN 
between  the  Hellenic  Navy  commands)  and  allow  applications  to  be  shared  among 
different  users.  The  OADS  system  is  able  to  produce  all  the  designed  reports  in  file 
format.  This  facility  allows  General  Staff  to  electronically  transfer  their  reports  as  soon  as 
all  the  commands  are  connected  to  a  common  network. 
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VII.  CONCLUSIONS  AND  LESSONS  LEARNED 


This  thesis  presented  the  design,  development,  and  implementation  of  the 
Operational  Activity  Database  System  (OADS)  application  on  a  standalone  computer  in 
the  Hellenic  Navy  General  Staff.  The  OADS  system  will  provide  the  General  Staff  with 
an  automated  system  to  create  its  primary  operational  activity  schedules.  OADS  supports 
this  mission  by  keeping  track  of  all  the  operational  activity  records,  maintaining  them, 
producing  reports,  and  providing  the  General  Staff  with  ad  hoc  information.  [Ref.  2] 

No  automated  system  is  currently  in  use  in  the  Genaral  Staff  and  all  the 
operational  activity  schedules  are  prepared  by  a  manual  filing  system,  which  is  slow, 
inaccurate,  and  prone  to  errors.  The  main  goal  of  developing  the  system  is  to  increase 
effectiveness,  efficiency,  and  accuracy  of  operational  activity  management.  After  OADS 
implementation,  it  is  hoped  that  most  of  the  current  problems  will  be  eliminated,  and 
future  enhancements  will  result  in  even  greater  efficiency  in  preparing  the  operational 
activity  schedules. 

System  analysis  and  design  tools  and  techniques  were  used  to  develop  the  system 
by  modeling  the  user  data  and  process  requirements.  Paradox  for  windows  5.0  was  used 
as  the  database  management  system  for  the  implementation  because  it  is  not  only 
powerful  but  also  meets  the  system's  developmental  requirements.  The  menu-driven 
environment  is  easy  to  use  and  quick  to  learn.  The  user  friendly  environment  will 
hopefully  eliminate  the  cultural  resistance  of  the  user  that  will  result  from  the  requirement 
to  switch  from  the  manual  system  to  an  automated  one. 
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It  is  hoped  that  this  thesis  will  be  the  motivation  for  other  efforts  to  develop  new 
systems  and  expand  or  update  existing  ones,  in  the  Hellenic  Navy.  [Ref.  2] 

Author's  expectation  is  that  the  Hellenic  Navy  General  Staff  will  adopt  the  OADS 
and  utilize  it  in  its  maximum  capabilities  in  order  to  effectively  prepare  the  Operational 
Activity  Schedule  of  the  Hellenic  Navy  units.  First  of  all,  senior  Officers  of  the  General 
Staff  must  be  convinced  for  the  benefits  of  OADS  and  the  easy  of  its  use. 

The  main  idea  of  this  thesis  and  the  thesis  of  Tsongas  [Ref.  2]  is  to  offer  to  the 
Hellenic  Navy  a  set  of  applications  that  will  easy  the  administrative,  operational,  and 
tactical  functions.  Hoping  that  the  future  Greek  Officers,  who  are  going  to  attend  the 
ITM  Curriculum  in  NPGS,  will  adopt  this  idea,  we  can  make  our  Navy  a  technologically 
updated  and  "ready  to  go". 
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APPENDIX  A:  DATA  DICTIONARY 


ELEMENT 

TYPE 

WIDTH 

DESCRIPTION 

COMMAND 

Command  Name 

Alpha 

20 

Command's  name. 

Commander  Name 

Alpha 

30 

Commander's  name. 

Commander  Rank 

Alpha 

20 

Commander's  rank. 

Base  Location 

Alpha 

30 

Command's  base  location. 

SUBCOMMAND 

Subcommand  Name 

Alpha 

10 

Subcommand's  name. 

Subcommander  Name 

Alpha 

30 

Subcommander's  name. 

Subcommander  Rank 

Alpha 

20 

Subcommander's  rank. 

Base  Location 

Alpha 

20 

Subcommand's  base  location. 

EXERCISE 

Exercise  No 

Number 

Exercise's  #. 

Exercise  Name 

Alpha 

20 

Exercise's  name. 

Date  begins 

Date 

Date  the  exercise  begins. 

Data  ends 

Date 

Date  the  exercise  ends. 

Geogr.  Location 

DRILL 

Alpha 

40 

Exercise's  location. 

Drill  No 

Number 

Drill's  #. 

Drill  Type 

Alpha 

10 

Drill's  type. 
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Drill  Date 

Date 

Date  drill  begins. 

Time  begins 

Time 

Time  drill  begins. 

Time  ends 

Time 

Time  drill  ends. 

Objective 

Alpha  60 

Drill's  objective. 

SHIP 

Hull  No 

Alpha  5 

Ship's  Hull  #. 

Name 

Alpha  20 

Ship's  name. 

Type 

Alpha  20 

Ship's  type. 

CO_Name 

Alpha  30 

CO's  name. 

CORank 

Alpha  20 

CO's  rank. 

Number  of  personnel 

Number 

Number  of  ship's  personnel. 

PORT 

Port  No 

Number 

Port's  #. 

Port  Name 

Alpha  30 

Port's  name. 

Location 

Alpha  30 

Port's  location. 

Watering  Capab. 

Logical  (Yes, No} 

If  port  has  watering 

capability. 

Fueling  Capab. 

Logical  {Yes, No} 

If  port  has  fueling  capability 

Maintenance  Capab. 

Logical{Yes,No} 

If  port  has  any  maintenance 

capability. 

SHIP-PORT 

Hull  No 

Alpha 

5 

Ship’s  Hull  #. 

Port  No 

Number 

Port's  #. 

Date  begins 

Date 

Date  ship  arrived  to  port. 
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Hours 


Number 


Hours  ship  remained  to  port 
in  the  same  condition. 

Ship's  State  Alpha  20  The  condition  of  the  ship. 

Amount  of  Fuel  in  It  Number  The  amount  of  fuel  that  a 

ship  received  in  a  port. 

COMMAND-EXERCISE 

Exercise  No  Number  Exercise's  #. 


Command  Name 

Alpha 

20 

Command's  name. 

Hours 

Number 

Hours  that  the  Command 

participated  in  the  Exercise. 

SUBCOMMAND-DRILL 

Subcommand  Name 

Alpha 

10 

Subcommand's  name. 

Drill  No 

Number 

Drill's  #. 

Hours 

Number 

Hours  that  the  Subcommand 

participated  in  the  drill. 

SHIP-DRILL 

Drill  No 

Number 

Drill's  #. 

Hull  No 

Alpha 

5 

Ship's  Hull  #. 

Hours 

Number 

Hours  that  the  Ship 

participated  in  the  drill. 

Torpedoes  used 

Number 

Number  of  torpedoes  used  by 

the  ship  during  the  drill. 

A/A  Missiles  used 

Number 

Number  of  A/A  missiles  used 

by  the  ship  during  the  drill. 
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A/S  Missiles  used 

Number 

Number  of  A/S  missiles  used 

by  the  ship  during  the  drill. 

Submarines  detected 

Number 

Number  of  submarines 

detected  by  the  ship  during 

the  drill. 
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APPENDIX  B:  DATA  FLOW  DIAGRAMS 


Data  return 
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Update  request 


USER 


Retrieval 

request 


Data  to  update 


OPERATIONAL 

ACTIVITY 

DATABASE 


Data  to  retrieve 


H  0 0 


Request  for 
command 


Request  for 
exercise 


Request  for 
subcommand 


UPDATE 

COMMAND 


UPDATE 

EXERCISE 


Jommand  update 


bxercise  update 


| - />  UPDATE  \ 

(  SUBCOMMAND^ 

Subcommand 

update 

^ ^ _ rwUPDATE  \  Subcoi 

Request  for  H  SUBCOMMAND  1 update 

subcommand/drill  \PER  DRILL 


U  UPDATE 
PORT 


Request  for 
ship/port 


Subcommand/drill  OPERATIONAL 

update _ £>  ACTIVITY 

DATABASE 

i - > 


Port  update 


UPDATE 

SHIP 

PER  PORT 


Ship/port 

update 


Request  for 
ship 


Request  for 
pomm  and/exercise 

Request  for 
drill 

OPERATIONAL 

ACTIVITY  <j . ( 

DATABASE  DriH  update' 


UPDATE 

SHIP 


/UPDATE  \ 
COMMAND  ] 
v  PER  EXERCISE/ 


Ship  update 


Command/exercise 

update 


l  Request  for 
ship/drill  [ 


~Ship7drill[ 

update 


UPDATE 

DRILL 


UPDATE 
SHIP  PER 
DRILL 
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Subcommand  to 
add 


Subcommand  to 
modify 


Subcommand  to 
delete 


/SUBCOMMAND^ 
ADDITION 
PROCESS  / 


/SUBCOMMAND^ 
1  DELETION  1 
\  PROCESS  I 


SUBCOMMAND 

MODIFICATION 

PROCESS 


'lew  subcommand 


Subcommand  to 
delete  data 


Modified 

subcommand 


{>  SUBCOMMAND 


USER 

1  STiip  to  add 

Ship  to  modity 

[ 

Ship  to  delete 

- 

\ 

z 

> 

7 

SHIP 

\ 

\ 

f  SHIP 

\ 

/SHIP 

\ 

ADDITION  j  | 

DELETION  ) 

[MODIFICATION 

PROCESS  J  ' 

^  PROCESS  j 

\PROCESS  , 

Ship  to  delete 

Modified  ship 

] 

New  ship 

aaia 

7 

data 

- 

SH 

ip 

- 
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;  Project  Name: 
Project  Path: 
Chart  File: 
Chart  Name: 
Created  On: 

|  Created  By: 
j  Modified  On: 

|  Modified  By: 


Activities 
c:\ecwin\ 
dfd00007.dfd 
UPDATE  PORT 
Nov-04- 1995 
Evangelos  MARINOS 
Nov-04- 1995 
Evangelos  MARINOS 


Port  to  add 


Port  to  modit 


Port  to  delete 


(  PORT  \ 

(  PORT  \ 

/PORT  \ 

f  ADDITION 

DELETION  ) 

MODIFICATION 

I  PROCESS^^ 

l  PROCESS  ! 

\PROCESS  y 

New  port 


Port  to  delete 
data 


Modified  port 
data 


- 1>  PORT  <]- 


59 


60 


Exercises/command 


Exercises  per 


2.2. 
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1.2.3 .3.1 


66 


APPENDIX  C  :  RELATIONS  AND  RELATIONAL  MODEL 


RELATIONS 

COMMMAND  (Command  Name1  ,  Commander  Name,  Commander  Rank,  Base 
Location) 

SUBCOMMAND  (Subcommand  Name.  Command  name 2 ,  Subcommander  Name, 
Subcommander  Rank,  Base  Location) 

EXERCISE  (Exercise  No.  Exercise  Name,  Date  begins,  Date  ends,  Geogr.  Location) 
DRILL  (Drill  No,  Exercise  No,  Drill  Type,  Drill  Date,  Time  begins,  Time  ends, 
Objective) 

SHIP  (Hull  No,  Subcommand  Name,  Name,  Type,  CO_Name,  CO  Rank,  Number  of 
personnel) 

PORT  (Port  No,  Port  Name,  Location,  Watering  Capab.,  Fueling  Capab.,  Maintenance 
Capab.) 

SHIP-PORT  (Hull  No.  Port  No.  Date  begins.  Hours,  Amount  of  Fuel  in  It,  Ship's  state) 
COMMAND-EXERCISE  (Exercise  No.  Command  Name,  Hours) 
SUBCOMMAND-DRILL  (Subcommand  Name.  Drill  No,  Hours) 

SHIP-DRILL  (Hull  No.  Drill  No.  Hours,  Torpedos  used,  A/A  Missiles  used,  A/S  Missiles 
used,  Submarines  detected). 


1  All  the  underlined  Attributes  are  the  key  Attributes  for  the  Relations 

2  All  the  Italic  Attributes  are  the  foreign  key  Attributes  for  the  Relations 
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RELATIONAL  MODEL 


Hull  No  I  Drill  No  I  Hours  jTorpedos  used  |A/A  Missiles  used 


SHIP-PORT _ _ 

Hull  No  Port  No  Data  begins  Hours 


PORT  _ \  _ 

Port  No  Port  Name  Location 


APPENDIX  D  :  BUSINESS  RULES 


ENTITY  COMMAND 

Uniqueness 

Null  Support 

Domain 

Command  Name 

Must  be  unique 

Non-null 

Command  name 

Commander  Name 

Nonunique 

May  be  null 

Name 

Commander  Rank 

Nonunique 

May  be  null 

Rank 

Base  Location 

Nonunique 

May  be  null 

Location 

ENTITY  SUBCOMMAND 

Uniqueness 

Null  Support 

Domain 

Subcommand  Name 

Must  be  unique 

Non-null 

Subcommand  name 

Command  Name 

Nonunique 

Non-null 

Command  name 

Subcommander  NameNonunique 

May  be  null 

Name 

Subcommander  Rank  Nonunique 

May  be  null 

Rank 

Base  Location 

Nonunique 

May  be  null 

Location 

User  rule:  SUBCOMMAND. Subcommander  Rank  not  exceed  COMMAND.Commander 
Rank 

Event:  Insert 

Condition:  SUBCOMMAND. Subcommander  Rank  >  COMMAND.Commander  Rank 
Where  SUBCOMMAND. Command  Name  =  COMMAND. Command  Name 
Action:  Reject  the  insert  transaction 

User  rule:  SUBCOMMAND. Command  Name  exists  in  COMMAND. Command  Name 
Event:  Insert 

Condition:  SUBCOMMAND. Command  Name  not  in  {COMM AND. Command  Name} 
Action:  Reject  the  insert  transaction 
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ENTITY  EXERCISE 


Uniqueness 

Exercise  No 

Must  be  unique 

Exercise  Name 

Nonunique 

Geogr.  Location 

Nonunique 

Date  begins 

Nonunique 

Date  ends 

Nonunique 

ENTITY  DRILL 

Uniqueness 

Drill  No 

Must  be  unique 

Exercise  No 

Nonunique 

Drill  Type 

Nonunique 

Drill  Date 

Nonunique 

Time  begins 

Nonunique 

Time  ends 

Nonunique 

Objective 

Nonunique 

Null  Support 

Domain 

Non-null 

Exercise  # 

May  be  null 

Exercise  name 

May  be  null 

Location 

May  be  null 

Date 

May  be  null 

Date 

Null  Support 

Domain 

Non-null 

Drill# 

Non-null 

Exercise  # 

May  be  null 

Drill  type 

May  be  null 

Date 

May  be  null 

Time 

May  be  null 

Time 

May  be  null 

Objective 

User  rule:  DRILL. Drill  Date  not  exceed  EXERCISE.Date  ends 
Event:  Insert 

Condition:  DRILL.Drill  Date  >  EXERCISE.Date  ends 

Where  DRILL.Exercise  No  =  EXERCISE.Exercise  No 
Action:  Reject  the  insert  transaction 

User  rule:  DRILL.Drill  Date  not  precede  EXERCISE.Date  begins 
Event:  Insert 

Condition:  DRILL.Drill  Date  <  EXERCISE.Date  begins 
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Where  DRILL. Exercise  No  =  EXERCISE.Exercise  No 
Action:  Reject  the  insert  transaction 

User  rule:  DRILL.Exercise  No  exists  in  EXERCISE.Exercise  No 
Event:  Insert 

Condition:  DRILL.Exercise  No  not  in  {EXERCISE.Exercise  No} 
Action:  Reject  the  insert  transaction 


ENTITY  SHIP 


Uniaueness 

Null  SuoDort 

Domain 

Hull  No 

Must  be  unique 

Non-null 

Hull# 

Subcommand  Name 

Nonunique 

Non-null 

Subcommand  Name 

Name 

Nonunique 

May  be  null 

Ship  Name 

Type 

Nonunique 

May  be  null 

Ship  Type 

CO_Name 

Nonunique 

May  be  null 

Name 

CORank 

Nonunique 

May  be  null 

Rank 

Number  of  personnel 

Nonunique 

May  be  null 

Number 

User  rule:  SHIP.CORank  not  exceed  SUBCOMMAND.Subcommander  Rank 
Event:  Insert 

Condition:  Ship.CO_Rank  >  SUBCOMMAND.Subcommander  Rank 

Where  SHIP. Subcommand  Name  =  SUBCOMMAND. Subcommand  Name 
Action:  Reject  the  insert  transaction 

User  rule:  SHIP.Subcommand  Name  exists  in  SUBCOMM.Subcommand  Name 
Event:  Insert 

Condition:  SHIP.Subcommand  Name  not  in  {SUB COMMAND. Subcommand  Name} 
Action:  Reject  the  insert  transaction 
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ENTITY  PORT 


Uniaueness 

Port  No 

Must  be  unique 

Port  Name 

Nonunique 

Location 

Nonunique 

Watering  Capab. 

Nonunique 

Fueling  Capab. 

Nonunique 

Maintenance  capab. 

Nonunique 

ENTITY  SHIP-PORT 

Uniaueness 

Port  No 

Nonunique 

Hull  No 

Nonunique 

Date  begins 

Nonunique 

Hours 

Nonunique 

Amount  of  Fuel  in  It 

Nonunique 

Ship's  state 

Nonunique 

Null  Support 

Domain 

Non-null 

Port# 

May  be  null 

Port  name 

May  be  null 

Location 

May  be  null 

Logical{Y,N} 

May  be  null 

Logical{Y,N} 

May  be  null 

Logical  {Y,N} 

Null  SuDDort 

Domain 

Non-null 

Port  # 

Non-null 

Hull# 

Non-null 

Date 

May  be  null 

Number 

May  be  null 

Number 

May  be  null 

Ship  state 

User  rule:  SHIP-PORT.Hull  No  exists  in  SHIP.Hull  No 
Event:  Insert 

Condition:  SHIP-PORT.Hull  No  not  in  {SHIP.Hull  No} 
Action:  Reject  the  insert  transaction 

User  rule:  SHIP-PORT.Drill  No  exists  in  DRTLT  .Drill  No 
Event:  Insert 

Condition:  SHIP-PORT.Drill  No  not  in  {DRILL. Drill  No} 
Action:  Reject  the  insert  transaction 
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ENTITY  COMMAND-EXERCISE 

Uniqueness 

Null  Support 

Domain 

Exercise  No 

Nonunique 

Non-null 

Exercise  # 

Command  Name 

Nonunique 

Non-null 

Command  name 

Hours 

Nonunique 

May  be  null 

Number 

User  rule:  COMMAND-EXERCISE.Command  Name  exists  in  COMMAND.Command 
Name 

Event:  Insert 

Condition:  COMMAND-EXERCISE.Command  Name  not  in  {COMMAND.Command 
Name} 

Action:  Reject  the  insert  transaction 

User  rule:  COMMAND-EXERCISE.Exercise  No  exists  in  EXERCISE.Exercise  No 
Event:  Insert 

Condition:  COMMAND-EXERCISE.Exercise  No  not  in  {EXERCISE.Exercise  No} 
Action:  Reject  the  insert  transaction 


ENTITY  SUBCOMMAND-DRILL 

Uniqueness 

Null  Support 

Domain 

Drill  No 

Nonunique 

Non-null 

Drill  # 

Subcommand  Name 

Nonunique 

Non-null 

Subcommand  name 

Hours 

Nonunique 

May  be  null 

Number 

User  rule:  SUBCOMMAND-DRILL.Subcommand  Name  exists  in 
SUB  COMMAND.  Subcommand  Name 
Event:  Insert 
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Condition:  SUBCOMMAND-DRILL.Subcomxnand  Name  not  in 
{SUBCOMMAND. Subcommand  Name} 

Action:  Reject  the  insert  transaction 

User  rule:  SUBCOMMAND-DRILL.Drill  No  exists  in  DRILL. Drill  No 
Event:  Insert 

Condition:  SUBCOMMAND-DRILL.Drill  No  not  in  {DRILL.Drill  No} 
Action:  Reject  the  insert  transaction 


ENTITY  SHIP-DRILL 


Uniaueness 

Null  Support 

Domain 

Hull  No 

Nonunique 

Non-null 

Hull# 

Drill  No 

Nonunique 

Non-null 

Drill# 

Hours 

Nonunique 

May  be  null 

Number 

Torpedos  used 

Nonunique 

May  be  null 

Number 

A/A  Missiles  used 

Nonunique 

May  be  null 

Number 

A/S  Missiles  used 

Nonunique 

May  be  null 

Number 

Submarines  detected 

Nonunique 

May  be  null 

Number 

User  rule:  SHIP-DRILL.Drill  No  exists  in  DRILL.Drill  No 
Event:  Insert 

Condition:  SHIP-DRILL.Drill  No  not  in  (DRILL.Drill  No} 
Action:  Reject  the  insert  transaction 

User  rule:  SHIP-DRILL.Hull  No  exists  in  SHIP.Hull  No 
Event:  Insert 

Condition:  SHIP-DRILL.Hull  No  not  in  {SHIP.Hull  No} 
Action:  Reject  the  insert  transaction 
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User  rule:  SHIP-DRILL.Hull  No  not  same  with  SHIP-PORT.Hull  No 
Event:  Insert 

Condition:  SHIP-DRILL.Hull  No  =  SHIP-PORT.Hull  No 

Where  DRILL.Drill  Date  =  SHIP-PORT.Date  begins 
and  DRILL.Drill  No  =  SHIP-DRILL.Drill  No 
Action:  Reject  the  insert  transaction 
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APPENDIX  E  :  PROCEDURES  FOR  INSTALLING  AND 


OPERATING  OADS 

A.  INSTALLATION  PROCEDURE 

To  run  any  Paradox  for  Windows  5.0  application,  Paradox  5.0  itself  must  be 
installed.  To  install  Paradox  for  Windows  5.0  the  user  has  to  run  the  Paradox  5.0 
installation  program.  Instructions  for  installing  Paradox  5.0  can  be  found  in  Paradox  5.0 
manuals. 

B.  SETTING  UP  THE  OADS  APPLICATION 

After  installing  Paradox  for  Windows  5.0  you  need  to  setup  the  OADS 
application.  Your  OADS  application  disk  includes  all  the  required  files  for  setting  up  the 
OADS  application.  The  user  has  to  perform  the  following  steps: 

•  Make  sure  that  you  are  in  the  Windows  environment. 

•  In  the  Windows  click  the  File  Manager  icon 

•  In  the  File  Manager  environment,  insert  the  OADS  application  disk,  and  copy 
the  files  of  the  disk  to  C:\pdoxwin\working  directory 

•  Exit  the  File  Manager,  and  click  the  Paradox  for  Windows  icon  to  enter  the 
Paradox  for  Windows  environment 

•  In  the  Paradox  for  Windows  environment,  go  to  the  working  directory 
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•  In  the  working  directory,  open  the  Setup.fsl  file,  in  order  to  go  to  the  OADS 
main  menu  screen 

C.  USING  THE  OADS  APPLICATION 

Using  the  mouse,  you  can  choose  the  Update  Submenu,  or  the  Retrieval  Submenu. 

If  you  want  to  update  (add,  delete,  or  modify)  data  of  the  OADS  application,  you 
have  to  click  the  Update  Subsystem  button,  which  bring  you  to  a  list  of  buttons 
(Command,  Subcommand,  Ship,  Exercise,  Drill,  etc.).  By  pressing  the  appropriate  button 
of  the  list,  you  are  transferred  to  the  data  that  you  want  to  update. 

If  you  want  to  retrieve  data  from  the  OADS  application,  you  have  to  click  the 
Retrieval  Subsystem  button,  which  brings  you  to  a  selection  list  of  Reports,  Records,  and 
Queries.  By  pressing  the  appropriate  button,  you  are  transferred  to  the  data  that  you  want 
to  retrieve. 

1.  Help  Screens 

Help  screens  are  included  in  the  OADS  application  and  are  designed  to  help  the 
user  follow  the  right  steps  for  each  procedures.  In  this  way  the  user  can  respond  correctly 
to  data  entry  and  updates  and  eliminate  potential  mistakes. 

2.  Printing  Outputs 

After  performing  a  report  operation  from  the  Reports  selection  of  the  Retrieval 
Subsystem,  there  is  the  opportunity  to  print  the  results  to  the  printer. 
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APPENDIX  F  :  APPLICATION  CODE 


Main  Menu 

method  pushButton(var  eventlnfo  Event) 
var  custForm  Form  endVar 
custForm.open("F  1 8") 
formRetumC'OK") 
endmethod 

method  pushButton(var  eventlnfo  Event) 

var  custForm  Form  endVar 

custForm.open("F7") 

formRetumC'OK") 

endmethod 

Update  Subsystem 

method  pushButton(var  eventlnfo  Event) 
var  custForm  Form  endVar 
custForm.open("F8") 
endmethod 

method  pushButton(var  eventlnfo  Event) 
var  custForm  Form  endVar 
custForm.open("Fl  1 ") 
endmethod 

method  pushButton(var  eventlnfo  Event) 
var  custForm  Form  endVar 
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custForm.open("F  1 0") 
endmethod 

method  pushButton(var  eventlnfo  Event) 
var  custForm  Form  endVar 
custForm.open("F  12") 
endmethod 

method  pushButton(var  eventlnfo  Event) 
var  custForm  Form  endVar 
custForm.open("F  1 3 ") 
endmethod 

method  pushButton(var  eventlnfo  Event) 
var  custForm  Form  endVar 
custForm. open("F  1 6") 
endmethod 

method  pushButton(var  eventlnfo  Event) 
var  custForm  Form  endVar 
custForm.open("F14") 
endmethod 

method  pushButton(var  eventlnfo  Event) 
var  custForm  Form  endVar 
custForm.open("F  15") 
endmethod 
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method  pushButton(var  eventlnfo  Event) 
var  custForm  Form  endVar 
custForm.open("F9") 
endmethod 

method  pushButton(var  eventlnfo  Event) 
var  custForm  Form  endVar 
custForm.open("F17") 
endmethod 

method  pushButton(var  eventlnfo  Event) 
var  custForm  Form  endVar 
custForm.open("startup") 
close() 

fomiRetum("OK") 

endmethod 

Command  Update 

method  arrive(var  eventlnfo  MoveEvent) 
var 

mainMenu  Menu 

filePop,  editPop,  recordPop  PopUpMenu 

endvar 

filePop.addText  ("New") 
filePop.addText  ("Exit") 
mainMenu.addPopUp("File",  filePop) 
editPop.addText  ("Cut") 
editPop.addText  ("Copy") 
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editPop.addText  ("Paste") 
mainMenu.addPopUp("Edit",  editPop) 
recordPop.addText  ("Next") 
recordPop.addText  ("Prev") 
recordPop.addSeparator  ( ) 
recordPop.addText  ("Edit  Data") 
recordPop.addText  ("Insert") 
recordPop.addText  ("Delete") 
mainMenu.addPopUp("Record",  recordPop) 
mainMenu.show  ( ) 
endmethod 

method  action(var  eventlnfo  ActionEvent) 

if  eventlnfo. id(  )  =  DataDeleteRecord  then 

if  msgQuestion  ("Delete?",  "Delete  this  record?")  =  "Yes"  then 

doDefault 

else 

eventlnfo .  setErrorCode(U  serError) 

endlf 

endlf 

endmethod 

method  pushButton(var  eventlnfo  Event) 

action(DataBeginEdit) 

endmethod 

method  pushButton(var  eventlnfo  Event) 
action(DataEndEdit) 
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endmethod 


method  pushButton(var  eventlnfo  Event) 

action(DataCancelRecord) 

endmethod 

method  pushButton(var  eventlnfo  Event) 
var 

userlnput,  promptString  String 
end  Var 

promptString  =  "Enter  the  Command  Name  here." 
userlnput  =  promptString 
userlnput. view("What  is  the  Command  Name?") 
if  userlnput  o  promptString  then 
if  not  Command_Name.locate("Command  Name",  userlnput)  then 
beep( ) 

message("Couldn't  find",  userlnput) 
sleep(lOOO) 
endlf 
endlf 

endmethod 

Subcommand  Update 

method  arrive(var  eventlnfo  MoveEvent) 
var 

mainMenu  Menu 

filePop,  editPop,  recordPop  PopUpMenu 

endvar 
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filePop.addText  ("New") 
filePop.addText  ("Exit") 
mainMenu.addPopUp("File",  filePop) 
editPop.addText  ("Cut") 
editPop.addText  ("Copy") 
editPop.addText  ("Paste") 
mainMenu.addPopUp("Edit",  editPop) 
recordPop.addText  ("Next") 
recordPop.addText  ("Prev") 
recordPop.addSeparator  ( ) 
recordPop.addText  ("Edit  Data") 
recordPop.addText  ("Insert") 
recordPop.addText  ("Delete") 
mainMenu.addPopUp("Record",  recordPop) 
mainMenu.show  (  ) 
endmethod 

method  action(var  eventlnfo  ActionEvent) 

if  eventlnfo. id( )  =  DataDeleteRecord  then 

if  msgQuestion  ("Delete?",  "Delete  this  record?")  =  "Yes"  then 

doDefault 

else 

eventlnfo.  setErrorCode(U  serError) 

endlf 

endlf 

endmethod 

method  open(var  eventlnfo  Event) 
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doDefault 

self.DataSource  =  "[COMMAND. Command  Name]" 
endmethod 

method  pushButton(var  eventlnfo  Event) 

action(DataB  eginEdit) 

endmethod 

method  pushButton(var  eventlnfo  Event) 

action(DataEndEdit) 

endmethod 

method  pushButton(var  eventlnfo  Event) 

action(DataCancelRecord) 

endmethod 

method  pushButton(var  eventlnfo  Event) 
var 

userlnput,  promptstring  String 
end  Var 

promptstring  =  "Enter  the  Subcommand  Name  here." 
userlnput  =  promptstring 

userlnput. view("What  is  the  Subcommand  Name?") 
if  userlnput  o  promptstring  then 

if  not  Subcommand_Name.locate("Subcommand  Name",  userlnput)  then 
beep( ) 

message(" Couldn't  find",  userlnput) 
sleep(lOOO) 
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endlf 

endlf 

endmethod 

method  pushButton(var  eventlnfo  Event) 

formRetum("  OK") 

endmethod 

Ship  Update 

method  arrive(var  eventlnfo  MoveEvent) 
var 

mainMenu  Menu 

filePop,  editPop,  recordPop  PopUpMenu 

endvar 

filePop.addText  ("New") 
filePop.addText  ("Exit") 
mainMenu.addPopUpC'File",  filePop) 
editPop.addText  ("Cut") 
editPop.addText  ("Copy") 
editPop.addText  ("Paste") 
mainMenu.addPopUp("Edit",  editPop) 
recordPop.addText  ("Next") 
recordPop.addText  ("Prev") 
recordPop.addSeparator  (  ) 
recordPop.addText  ("Edit  Data") 
recordPop.addText  ("Insert") 
recordPop.addText  ("Delete") 
mainMenu.addPopUp("Record" ,  recordPop) 
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mainMenu.show  ( ) 
endmethod 

method  action(var  eventlnfo  ActionEvent) 

if  eventlnfo. id( )  =  DataDeleteRecord  then 

if  msgQuestion  ("Delete?",  "Delete  this  record?")  =  "Yes"  then 

doDefault 

else 

eventInfo.setErrorCode(UserError) 

endlf 

endlf 

endmethod 

method  pushButton(var  eventlnfo  Event) 

action(DataBeginEdit) 

endmethod 

method  pushButton(var  eventlnfo  Event) 

action(DataEndEdit) 

endmethod 

method  pushButton(var  eventlnfo  Event) 

action(DataCancelRecord) 

endmethod 

method  pushButton(var  eventlnfo  Event) 
var 

userlnput,  promptstring  String 


87 


endVar 

promptstring  =  "Enter  the  Hull  Number  here." 
userlnput  =  promptstring 
userInput.view("What  is  the  Hull  Number?") 
if  userlnput  o  promptstring  then 
if  not  Hull_No.locate("Hull  No",  userlnput)  then 
beep( ) 

message(" Couldn't  find",  userlnput) 
sleep(lOOO) 
endlf 
endlf 
endmethod 

method  pushButton(var  eventlnfo  Event) 

formRetum("OK") 

endmethod 

Port  Update 

method  action(var  eventlnfo  ActionEvent) 

if  eventlnfo. id(  )  =  DataDeleteRecord  then 

if  msgQuestion  ("Delete?",  "Delete  this  record?")  =  "Yes"  then 

doDefault 

else 

eventlnfo.setErrorCode(UserError) 

endlf 

endlf 

endmethod 
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method  arrive(var  eventlnfo  MoveEvent) 
var 

mainMenu  Menu 

filePop,  editPop,  recordPop  PopUpMenu 

endvar 

filePop.addText  ("New") 
filePop.addText  ("Exit") 
mainMenu.addPopUp("File",  filePop) 
editPop.addText  ("Cut") 
editPop.addText  ("Copy") 
editPop.addText  ("Paste") 
mainMenu.addPopUp("Edit",  editPop) 
recordPop.addText  ("Next") 
recordPop.addText  ("Prev") 
recordPop.addSeparator  (  ) 
recordPop.addText  ("Edit  Data") 
recordPop.addText  ("Insert") 
recordPop.addText  ("Delete") 
mainMenu.addPopUp("Record",  recordPop) 
mainMenu.show  ( ) 
endmethod 

method  pushButton(var  eventlnfo  Event) 

action(DataBeginEdit) 

endmethod 

method  pushButton(var  eventlnfo  Event) 
action(DataEndEdit) 
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endmethod 


method  pushButton(var  eventlnfo  Event) 

action(DataCancelRecord) 

endmethod 

method  pushButton(var  eventlnfo  Event) 
var 

userlnput,  promptstring  String 
endVar 

promptstring  =  "Enter  the  Port  Number  here." 
userlnput  =  promptstring 
userlnput. view("What  is  the  Port  Number?") 
if  userlnput  o  promptstring  then 
if  not  Port_No.locate("Port  No",  userlnput)  then 
beep( ) 

message(" Couldn’t  find",  userlnput) 
sleep(lOOO) 
endlf 
endlf 

endmethod 

method  pushButton(var  eventlnfo  Event) 

formReturn("OK") 

endmethod 

Ship  Per  Port  Update 

method  action(var  eventlnfo  ActionEvent) 
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if  eventInfo.id(  )  =  DataDeleteRecord  then 

if  msgQuestion  ("Delete?",  "Delete  this  record?")  =  "Yes"  then 

doDefault 

else 

eventlnfo  .setErrorCode(U  serError) 

endlf 

endlf 

endmethod 

method  action(var  eventlnfo  ActionEvent) 

if  eventInfo.id( )  =  DataDeleteRecord  then 

if  msgQuestion  ("Delete?",  "Delete  this  record?")  =  "Yes"  then 

doDefault 

else 

eventlnfo .  setErrorCode(U  serError) 

endlf 

endlf 

endmethod 

method  change Value(var  eventlnfo  ValueEvent) 
if  eventInfo.newValue( )  >  Today( )  then 
eventlnfo. setErrorCode(CanNotDepart) 
message("Date  can't  be  later  than  today's  date.") 
sleep(lOOO) 
endlf 

endmethod 

method  pushButton(var  eventlnfo  Event) 
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action(DataBeginEdit) 

endmethod 

method  pushButton(var  eventlnfo  Event) 

action(DataEndEdit) 

endmethod 

method  pushButton(var  eventlnfo  Event) 

action(DataCancelRecord) 

endmethod 

method  pushButton(var  eventlnfo  Event) 
var 

userlnputl,  promptstring  1  String 
userlnput2,  promptString2  String 
end  Var 

promptstring  1  =  "Enter  the  Hull  Number  here." 

userlnputl  =  promptStringl 

promptString2  =  "Enter  the  Port  Number  here." 

userlnput2  =  promptString2 

userlnputl. view(" What  is  the  Hull  Number?") 

userInput2.view("What  is  the  Port  Number?") 

if  userlnputl  o  promptStringl  and  userlnput2  o  promptString2  then 
if  not  Hull_No.locate("Hull  No",  userlnputl)  then 
beep( ) 

message(" Couldn't  find",  userlnputl) 

else  if  not  Port_No.locate("Port  No",  userlnput2)  then 
beep( ) 
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message("Couldn't  find",  userlnput2) 
endif 
endlf 
endif 

endmethod 

method  pushButton(var  eventlnfo  Event) 

formRetumO'OK") 

endmethod 

Exercise  Per  Command  Update 

method  action(var  eventlnfo  ActionEvent) 

if  eventInfo.id( )  =  DataDeleteRecord  then 

if  msgQuestion  ("Delete?",  "Delete  this  record?")  =  "Yes"  then 

doDefault 

else 

eventlnfo .  setErrorCode(U  serError) 

endif 

endif 

endmethod 

method  arrive(var  eventlnfo  MoveEvent) 
var 

mainMenu  Menu 

filePop,  editPop,  recordPop  PopUpMenu 

endvar 

filePop.addText  ("New") 
filePop.addText  ("Exit") 
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mainMenu.addPopUp("File",  filePop) 
editPop.addText  ("Cut") 
editPop.addText  ("Copy") 
editPop.addText  ("Paste") 
mainMenu.addPopUp("Edit",  editPop) 
recordPop.addText  ("Next") 
recordPop.addText  ("Prev") 
recordPop.addSeparator  ( ) 
recordPop.addText  ("Edit  Data") 
recordPop.addText  ("Insert") 
recordPop.addText  ("Delete") 
mainMenu.addPopUp("Record",  recordPop) 
mainMenu.show  ( ) 
endmethod 

method  action(var  eventlnfo  ActionEvent) 

if  eventInfo.id( )  =  DataDeleteRecord  then 

if  msgQuestion  ("Delete?",  "Delete  this  record?")  =  "Yes"  then 

doDefault 

else 

eventlnfo.  setErrorCode(U  serError) 

endlf 

endlf 

endmethod 

method  pushButton(var  eventlnfo  Event) 

action(DataBeginEdit) 

endmethod 
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method  pushButton(var  eventlnfo  Event) 

action(DataEndEdit) 

endmethod 

method  pushButton(var  eventlnfo  Event) 

action(DataCancelRecord) 

endmethod 

method  pushButton(var  eventlnfo  Event) 
var 

userlnputl,  promptStringl  String 
userlnput2,  promptString2  String 
end  Var 

promptStringl  =  "Enter  the  Command  Name  here." 
userlnputl  =  promptStringl 

promptString2  =  "Enter  the  Exercise  Number  here." 
userlnput2  =  promptString2 
userlnputl. vie w(" What  is  the  Command  Name?") 
userInput2.view("What  is  the  Exercise  Number?") 
if  userlnputl  o  promptStringl  and  userlnput2  o  promptString2  then 
if  not  Command_Name.locate("Command  Name",  userlnputl)  then 
beep( ) 

message("Couldn't  find",  userlnputl) 

else  if  not  Exercise_No.locate("Exercise  No",  userlnput2)  then 
beep( ) 

message("Couldn't  find",  userlnput2) 
sleep(lOOO) 
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endlf 


endlf 

endlf 

endmethod 

method  pushButton(var  eventlnfo  Event) 

formRetum("OK") 

endmethod 

Drill  Per  Subcommand  Update 

method  action(var  eventlnfo  ActionEvent) 

if  eventInfo.id( )  =  DataDeleteRecord  then 

if  msgQuestion  ("Delete?",  "Delete  this  record?")  =  "Yes"  then 

doDefault 

else 

eventlnfo.  setErrorCode(U  serError) 

endlf 

endlf 

endmethod 

method  action(var  eventlnfo  ActionEvent) 

if  eventInfo.id( )  =  DataDeleteRecord  then 

if  msgQuestion  ("Delete?",  "Delete  this  record?")  =  "Yes"  then 

doDefault 

else 

eventInfo.setErrorCode(UserError) 

endlf 

endlf 
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endmethod 


method  arrive(var  eventlnfo  MoveEvent) 
var 

mainMenu  Menu 

filePop,  editPop,  recordPop  PopUpMenu 

endvar 

filePop.  addText  ("New") 
filePop.addText  ("Exit") 
mainMenu.addPopUp("File",  filePop) 
editPop. addText  ("Cut") 
editPop.addText  ("Copy") 
editPop.addText  ("Paste") 
mainMenu.addPopUp("Edit" ,  editPop) 
recordPop. addText  ("Next") 
recordPop.addText  ("Prev") 
recordPop.addSeparator  (  ) 
recordPop.addText  ("Edit  Data") 
recordPop.addText  ("Insert") 
recordPop.addText  ("Delete") 
mainMenu.addPopUp("Record",  recordPop) 
mainMenu.  show  ( ) 
endmethod 

method  pushButton(var  eventlnfo  Event) 

action(DataBeginEdit) 

endmethod 
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method  pushButton(var  eventlnfo  Event) 

action(DataEndEdit) 

endmethod 

method  pushButton(var  eventlnfo  Event) 

action(DataCancelRecord) 

endmethod 

method  pushButton(var  eventlnfo  Event) 
var 

userlnputl,  promptStringl  String 
userlnput2,  promptString2  String 
endVar 

promptStringl  =  "Enter  the  Subcommand  Name  here." 
userlnputl  =  promptStringl 
promptString2  =  "Enter  the  Drill  Number  here." 
userlnput2  =  promptString2 

userlnputl. view(" What  is  the  Subcommand  Name?") 
userInput2.view("What  is  the  Drill  Number?") 

if  userlnputl  o  promptStringl  and  userlnput2  o  promptString2  then 
if  not  Subcommand_Name.locate("Subcommand  Name",  userlnputl)  then 
beep( ) 

message("Couldn't  find",  userlnputl) 

else  if  not  Drill_No.locate("Drill  No",  userlnput2)  then 
beep( ) 

message("Couldn't  find",  userlnput2) 

sleep(lOOO) 

endlf 
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endlf 


endlf 

endmethod 

method  pushButton(var  eventlnfo  Event) 

formRetum("OK") 

endmethod 

Drill  Per  Ship  Update 

method  action(var  eventlnfo  ActionEvent) 

if  eventInfo.id( )  =  DataDeleteRecord  then 

if  msgQuestion  ("Delete?",  "Delete  this  record?")  =  "Yes"  then 

doDefault 

else 

eventlnfo.setErrorCode(UserError) 

endlf 

endlf 

endmethod 

method  action(var  eventlnfo  ActionEvent) 

if  eventlnfo. id( )  =  DataDeleteRecord  then 

if  msgQuestion  ("Delete?",  "Delete  this  record?")  =  "Yes"  then 

doDefault 

else 

eventlnfo.  setErrorCode(U  serError) 

endlf 

endlf 

endmethod 
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method  pushButton(var  eventlnfo  Event) 


var 

userlnputl,  promptStringl  String 
userlnput2,  promptString2  String 
endVar 

promptStringl  =  "Enter  the  Hull  Number  here." 

userlnputl  =  promptStringl 

promptString2  =  "Enter  the  Drill  Number  here." 

userlnput2  =  promptString2 

userlnputl  .view("What  is  the  Hull  Number?") 

userInput2.view("What  is  the  Drill  Number?") 

if  userlnputl  o  promptStringl  and  userlnput2  o  promptString2  then 
if  not  Hull_No.locate("Hull  No",  userlnputl)  then 
beep( ) 

message(" Couldn't  find",  userlnputl) 

else  if  not  Drill_No.locate("Drill  No",  userlnput2)  then 
beep( ) 

message("Couldn't  find",  userlnput2) 
sleep(lOOO) 
endlf 
endlf 
endlf 
endmethod 

method  pushButton(var  eventlnfo  Event) 

action(DataBeginEdit) 

endmethod 
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method  pushButton(var  eventlnfo  Event) 

action(DataEndEdit) 

endmethod 

method  pushButton(var  eventlnfo  Event) 

action(DataCancelRecord) 

endmethod 

method  pushButton(var  eventlnfo  Event) 

formRetum("OK") 

endmethod 

Exercise  Update 

method  action(var  eventlnfo  ActionEvent) 

if  eventInfo.id( )  =  DataDeleteRecord  then 

if  msgQuestion  ("Delete?",  "Delete  this  record?")  =  "Yes"  then 

doDefault 

else 

eventlnfo. setErrorCode(UserError) 

endlf 

endlf 

endmethod 

method  arrive(var  eventlnfo  MoveEvent) 
var 

mainMenu  Menu 

filePop,  editPop,  recordPop  PopUpMenu 
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endvar 

filePop.addText  ("New") 
fllePop.addText  ("Exit") 
mainMenu.addPopUp("File",  filePop) 
editPop.addText  ("Cut") 
editPop.addText  ("Copy") 
editPop.addText  ("Paste") 
mainMenu.  addPopUp("  Edit" ,  editPop) 
recordPop.addText  ("Next") 
recordPop.addText  ("Prev") 
recordPop.addSeparator  ( ) 
recordPop.addText  ("Edit  Data") 
recordPop.addText  ("Insert") 
recordPop.addText  ("Delete") 
mainMenu.addPopUp("Record",  recordPop) 
mainMenu.  show  (  ) 
endmethod 

method  changeValue(var  eventlnfo  ValueEvent) 

if  eventlnfo. newValue( )  >  Today( )  then 

eventlnfo.setErrorCode(CanNotDepart) 

message("Date  can't  be  later  than  today's  date.") 

sleep(lOOO) 

endlf 

endmethod 

method  changeValue(var  eventlnfo  ValueEvent) 
if  eventlnfo. newValue( )  >  Today( )  then 
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eventlnfo .  setErrorCode(CanN  otDepart) 
message("Date  can't  be  later  than  today's  date.") 
sleep(lOOO) 
endlf 

if  eventInfo.newValue( )  <  "[EXERCISE.Date  begins]"  then 

eventlnfo .  setErrorCode(CanN  otDepart) 

message("Date  can't  be  earlier  than  Date  begins.") 

sleep(lOOO) 

endlf 

endmethod 

method  pushButton(var  eventlnfo  Event) 

action(DataBeginEdit) 

endmethod 

method  pushButton(var  eventlnfo  Event) 

action(DataEndEdit) 

endmethod 

method  pushButton(var  eventlnfo  Event) 

action(DataCancelRecord) 

endmethod 

method  pushButton(var  eventlnfo  Event) 
var 

userlnput,  promptstring  String 
end  Var 

promptstring  =  "Enter  the  Exercise  Number  here." 
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userlnput  =  promptstring 
userInput.view("What  is  the  Exercise  Number?") 
if  userlnput  <>  promptString  then 
if  not  Exercise_No.locate("Exercise  No",  userlnput)  then 
beep( ) 

message(" Couldn't  find",  userlnput) 
sleep(lOOO) 
endlf 
endlf 

endmethod 

method  arrive(var  eventlnfo  MoveEvent) 
var 

mainMenu  Menu 

filePop,  editPop,  recordPop  PopUpMenu 

endvar 

filePop.addText  ("New") 
filePop.addText  ("Exit") 
mainMenu. addPopUp( "File " ,  filePop) 
editPop.  addText  ("Cut") 
editPop.addText  ("Copy") 
editPop.addText  ("Paste") 
mainMenu.  addPopUp("  Edit " ,  editPop) 
recordPop.addText  ("Next") 
recordPop.addText  ("Prev") 
recordPop.addSeparator  ( ) 
recordPop.addText  ("Edit  Data") 
recordPop.addText  ("Insert") 
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recordPop.addText  ("Delete") 
mainMenu.addPopUp("Record",  recordPop) 
mainMenu.show  ( ) 
endmethod 

method  pushButton(var  eventlnfo  Event) 

formRetum("OK") 

endmethod 

Drill  Update 

method  action(var  eventlnfo  ActionEvent) 

if  eventInfo.id( )  =  DataDeleteRecord  then 

if  msgQuestion  ("Delete?",  "Delete  this  record?")  =  "Yes"  then 

doDefault 

else 

eventlnfo .  setError  C  ode(U  serError) 

endlf 

endlf 

endmethod 

method  change Value(var  eventlnfo  ValueEvent) 
if  eventInfo.newValue( )  >  Today( )  then 
eventlnfo.  setErrorCode(CanN  otDepart) 
message("Date  can’t  be  later  than  today’s  date.") 
sleep(lOOO) 
endlf 

if  eventInfo.newValue( )  <  "[EXERCISE.Date  begins]"  then 
eventlnfo .  setErrorCode(CanN  otDepart) 
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message("Date  can't  be  earlier  than  exercise's  date.") 

sleep(lOOO) 

endlf 

if  eventInfo.newValue( )  >  "[EXERCISE.Date  ends]"  then 

eventlnfo.setErrorCode(CanNotDepart) 

message("Date  can't  be  later  than  exercise's  date.") 

sleep(lOOO) 

endlf 

endmethod 

method  pushButton(var  eventlnfo  Event) 

action(DataBeginEdit) 

endmethod 

method  pushButton(var  eventlnfo  Event) 

action(DataEndEdit) 

endmethod 

method  pushButton(var  eventlnfo  Event) 

action(DataCancelRecord) 

endmethod 

method  pushButton(var  eventlnfo  Event) 
var 

userlnput,  promptstring  String 
end  Var 

promptstring  =  "Enter  the  Drill  Number  here." 
userlnput  =  promptstring 


106 


userInput.view("What  is  the  Drill  Number?") 
if  userlnput  o  promptstring  then 
if  not  Drill_No.locate("Drill  No",  userlnput)  then 
beep( ) 

message("Couldn't  find",  userlnput) 
sleep(lOOO) 
endlf 
endlf 

endmethod 

method  pushButton(var  eventlnfo  Event) 

formRetum("OK") 

endmethod 

method  arrive(var  eventlnfo  MoveEvent) 
var 

mainMenu  Menu 

filePop,  editPop,  recordPop  PopUpMenu 

endvar 

filePop.addText  ("New") 
filePop.addText  ("Exit") 
mainMenu.addPopUp("File",  filePop) 
editPop.addText  ("Cut") 
editPop.addText  ("Copy") 
editPop.addText  ("Paste") 
mainMenu.addPopUp("Edit",  editPop) 
recordPop. addText  ("Next") 
recordPop. addText  ("Prev") 
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recordPop.addSeparator  ( ) 
recordPop.addText  ("Edit  Data") 
recordPop.addText  ("Insert") 
recordPop.addText  ("Delete") 
mainMenu.addPopUp("Record" ,  recordPop) 
mainMenu.show  ( ) 
endmethod 

Retrieval  Subsystem 

method  pushButton(var  eventlnfo  Event) 
var 

custForm  Form 

end  Var 

custForm.open("F19") 

endmethod 

method  pushButton(var  eventlnfo  Event) 
var 

custForm  Form 

end  Var 

custForm.open("F20") 

endmethod 

method  pushButton(var  eventlnfo  Event) 
var 

custForm  Form 

end  Var 

custForm.open("F2 1 ") 
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endmethod 


method  pushButton(var  eventlnfo  Event) 
var 

custForm  Form 

end  Var 

custForm.open("startup") 

close() 

formRetum("OK") 

endmethod 

Reports 

method  pushButton(var  eventlnfo  Event) 
var 

custRpt  Report 

end  Var 

custRpt.open("rl") 

endmethod 

method  pushButton(var  eventlnfo  Event) 
var 

custRpt  Report 

end  Var 

custRpt.print("rl ") 
endmethod 

method  pushButton(var  eventlnfo  Event) 
var 
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custRpt  Report 


endVar 

custRpt.open("R2") 

endmethod 

method  pushButton(var  eventlnfo  Event) 
var 

custRpt  Report 

endVar 

custRpt.print("r2") 

endmethod 

method  pushButton(var  eventlnfo  Event) 
var 

custRpt  Report 

endVar 

custRpt.  open("R3 ") 
endmethod 

method  pushButton(var  eventlnfo  Event) 
var 

custRpt  Report 

endVar 

custRpt.print("r3 ") 
endmethod 

method  pushButton(var  eventlnfo  Event) 
var 
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custRpt  Report 


endVar 

custRpt.open("r4") 

endmethod 

method  pushButton(var  eventlnfo  Event) 
var 

custRpt  Report 

endVar 

custRpt.print("r4") 

endmethod 

method  pushButton(var  eventlnfo  Event) 
var 

custRpt  Report 

endVar 

custRpt.  open("r5") 
endmethod 

method  pushButton(var  eventlnfo  Event) 
var 

custRpt  Report 

endVar 

custRpt.print("r5 ") 
endmethod 

method  pushButton(var  eventlnfo  Event) 
var 
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custForm  Form 


endVar 

custForm.open("F7") 

formRetum("OK") 

endmethod 

Records 

method  pushButton(var  eventlnfo  Event) 
var 

custForm  Form 

endVar 

custForm.open("F  1 ") 
endmethod 

method  pushButton(var  eventlnfo  Event) 
var 

custForm  Form 

endVar 

custForm.open("F3") 

endmethod 

method  pushButton(var  eventlnfo  Event) 
var 

custForm  Form 

endVar 

custForm.open("F6") 

endmethod 


112 


method  pushButton(var  eventlnfo  Event) 
var 

custForm  Form 

endVar 

custForm.open("F2") 

endmethod 

method  pushButton(var  eventlnfo  Event) 
var 

custForm  Form 

endVar 

custForm.open("F5 ") 
endmethod 

method  pushButton(var  eventlnfo  Event) 
var 

custForm  Form 

endVar 

custForm.open("F4") 

endmethod 

method  pushButton(var  eventlnfo  Event) 
var 

custForm  Form 

endVar 

custForm.open("F7") 

formRetumfOK") 

endmethod 
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Queries 

method  pushButton(var  eventlnfo  Event) 
var 

tv  Table  View 
endVar 

if  ExecuteQBEFile("ql2.qbe",  "Answer.db”)  then 
tv.open("Answer.db") 

else 

msgStop("Stop",  "Couldn't  run  the  query.") 

endlf 

endmethod 

method  pushButton(var  eventlnfo  Event) 
var 

tv  Table  View 
endVar 

if  ExecuteQBEFile("ql3.qbe",  "Answer.db")  then 
tv.open("Answer.db") 

else 

msgStop("Stop",  "Couldn't  run  the  query.") 

endlf 

endmethod 

method  pushButton(var  eventlnfo  Event) 
var 

tv  Table  View 
endVar 
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if  ExecuteQBEFile("q2.qbe",  "Answer.db")  then 
tv.open("Answer.db") 

else 

msgStopO'Stop",  "Couldn't  run  the  query.") 

endlf 

endmethod 

method  pushButton(var  eventlnfo  Event) 
var 

tv  Table  View 
endVar 

if  ExecuteQBEFile("q7.qbe",  "Answer.db")  then 
tv.open("  Answer.db") 

else 

msgStopO'Stop",  "Couldn't  run  the  query.") 

endlf 

endmethod 

method  pushButton(var  eventlnfo  Event) 
var 

tv  TableView 
endVar 

if  ExecuteQBEFile("q3.qbe",  "Answer.db")  then 
tv.openO' Answer.db") 

else 

msgStopO'Stop",  "Couldn't  run  the  query.") 

endlf 

endmethod 


115 


method  pushButton(var  eventlnfo  Event) 
var 

tv  TableView 
endVar 

if  ExecuteQBEFile("q8.qbe",  "Answer.db")  then 
tv.open("Answer.db") 

else 

msgStop("Stop",  "Couldn't  ran  the  query.") 

endlf 

endmethod 

method  pushButton(var  eventlnfo  Event) 
var 

tv  TableView 
endVar 

if  ExecuteQBEFile("ql0.qbe”,  "Answer.db")  then 
tv.open("  Answer.db") 

else 

msgStop("Stop",  "Couldn't  run  the  query.") 

endlf 

endmethod 

method  pushButton(var  eventlnfo  Event) 
var 

tv  TableView 
endVar 

if  ExecuteQBEFile("q9.qbe",  "Answer.db")  then 
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tv.open("Answer.db") 

else 

msgStopO'Stop",  "Couldn't  run  the  query.") 

endlf 

endmethod 

method  pushButton(var  eventlnfo  Event) 
var 

tv  Table  View 
end  Var 

if  ExecuteQBEFile("ql4.qbe",  "Answer.db")  then 
tv.open("Answer.db") 

else 

msgStop("Stop",  "Couldn't  run  the  query.") 

endlf 

endmethod 

method  pushButton(var  eventlnfo  Event) 
var 

tv  TableView 
end  Var 

if  ExecuteQBEFile("ql.qbe",  "Answer.db")  then 
tv.open("  Answer.db") 

else 

msgStop("Stop",  "Couldn't  run  the  query.") 

endlf 

endmethod 
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method  pushButton(var  eventlnfo  Event) 
var 

tv  Table  View 
endVar 

if ExecuteQBEFile("ql l.qbe",  "Answer.db")  then 
tv.open("Answer.db") 

else 

msgStop(”Stop",  "Couldn't  run  the  query.") 

endlf 

endmethod 

method  pushButton(var  eventlnfo  Event) 
var 

tv  Table  View 
endVar 

if  ExecuteQBEFile("q5.qbe",  "Answer.db")  then 
tv.open("  Answer.db") 

else 

msgStop("Stop",  "Couldn't  run  the  query.") 

endlf 

endmethod 

method  pushButton(var  eventlnfo  Event) 
var 

tv  Table  View 
endVar 

if  ExecuteQBEFile("q4.qbe",  "Answer.db")  then 
tv.open("  Answer.db") 
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else 


msgStop("Stop",  "Couldn't  run  the  query.") 

endlf 

endmethod 

method  pushButton(var  eventlnfo  Event) 
var 

tv  Table  View 
end  Var 

if  ExecuteQBEFile("ql5.qbe",  "Answer.db")  then 
tv.open("Answer.db") 

else 

msgStop("Stop",  "Couldn't  run  the  query.") 

endlf 

endmethod 

method  pushButton(var  eventlnfo  Event) 
var 

tv  Table  View 
end  Var 

if  ExecuteQBEFile("q6.qbe",  "Answer.db")  then 
tv.open("  Answer.db") 

else 

msgStop("Stop",  "Couldn't  run  the  query.") 

endlf 

endmethod 

method  pushButton(var  eventlnfo  Event) 
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var 


custForm  Form 

endVar 

custForm.open("F7") 

formRetum("OK") 

endmethod 

Command  Records  Per  Exercise 

method  pushButton(var  eventlnfo  Event) 

action(DataNextRecord) 

endmethod 

method  pushButton(var  eventlnfo  Event) 

action(DataPriorRecord) 

endmethod 

method  pushButton(var  eventlnfo  Event) 
var 

userlnput,  promptString  String 
endVar 

promptString  =  "Enter  the  Command  Name  here." 
userlnput  =  promptString 
userInput.view("What  is  the  Command  Name?") 
if  userlnput  o  promptString  then 

if  not  Command_Name.locate("Command  Name",  userlnput)  then 
beep( ) 

message("Couldn't  find",  userlnput) 
sleep(lOOO) 
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endlf 

endlf 

endmethod 

Subcommand  Records  Per  Command 

method  pushButton(var  eventlnfo  Event) 
var 

userlnput,  promptstring  String 
endVar 

promptstring  =  "Enter  the  Command  Name  here." 
userlnput  =  promptstring 

userInput.view("What  is  the  Command  Name?") 
if  userlnput  o  promptstring  then 
if  not  Command_Name.locate("Command  Name",  userlnput)  then 
beep( ) 

message("Couldn't  find",  userlnput) 
sleep(lOOO) 
endlf 
endlf 

endmethod 

method  pushButton(var  eventlnfo  Event) 

formRetum("OK") 

endmethod 

method  pushButton(var  eventlnfo  Event) 

action(DataNextRecord) 

endmethod 
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method  pushButton(var  eventlnfo  Event) 

action(DataPriorRecord) 

endmethod 

method  pushButton(var  eventlnfo  Event) 

formRetumO’OK") 

endmethod 

Drill  Records  Per  Ship 

method  pushButton(var  eventlnfo  Event) 
var 

userlnput,  promptstring  String 
endVar 

promptstring  =  "Enter  the  Hull  Number  here." 
userlnput  =  promptstring 
userlnput. view("What  is  the  Hull  Number?") 
if  userlnput  o  promptstring  then 
if  not  Hull_No.locate("Hull  No",  userlnput)  then 
beep( ) 

message(" Couldn't  find",  userlnput) 
sleep(lOOO) 
endlf 
endlf 

endmethod 

method  pushButton(var  eventlnfo  Event) 
action(DataN  extRecord) 
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endmethod 


method  pushButton(var  eventlnfo  Event) 

action(DataPriorRecord) 

endmethod 

method  pushButton(var  eventlnfo  Event) 

formRetum("OK") 

endmethod 

Ship  Records  Per  Port 

method  pushButton(var  eventlnfo  Event) 
var 

userlnput,  promptstring  String 
endVar 

promptstring  =  "Enter  the  Port  Number  here." 
userlnput  =  promptstring 
userlnput. view("What  is  the  Port  Number?") 
if  userlnput  o  promptString  then 
if  not  Port_No.locate("Port  No",  userlnput)  then 
beep( ) 

message("Couldn't  find",  userlnput) 
sleep(lOOO) 
endlf 
endlf 

endmethod 

method  pushButton(var  eventlnfo  Event) 
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formRetum("OK") 

endmethod 

method  pushButton(var  eventlnfo  Event) 

action(DataN  extRecord) 

endmethod 

method  pushButton(var  eventlnfo  Event) 

action(DataPriorRecord) 

endmethod 

Drill  Records  Per  Ship  Per  Subcommand 

method  pushButton(var  eventlnfo  Event) 
var 

userlnput,  promptString  String 
end  Var 

promptString  =  "Enter  the  Subcommand  Name  here." 
userlnput  =  promptString 

userlnput. view("What  is  the  Subcommand  Name?") 
if  userlnput  o  promptString  then 

if  not  Subcommand_Name.locate("Subcommand  Name",  userlnput)  then 
beep( ) 

message(" Couldn't  find",  userlnput) 
sleep(lOOO) 
endlf 
endlf 
endmethod 
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method  pushButton(var  eventlnfo  Event) 

action(DataN  extRecord) 

endmethod 

method  pushButton(var  eventlnfo  Event) 

action(DataPriorRecord) 

endmethod 

method  pushButton(var  eventlnfo  Event) 

formRetum("OK") 

endmethod 

Drill  Records  Per  Exercise 

method  pushButton(var  eventlnfo  Event) 
var 

userlnput,  promptstring  String 
end  Var 

promptstring  =  "Enter  the  Exercise  Number  here." 
userlnput  =  promptString 

userInput.view("What  is  the  Exercise  Number?") 
if  userlnput  o  promptString  then 
if  not  Exercise_No.locate("Exercise  No",  userlnput)  then 
beep( ) 

message("Couldn't  find",  userlnput) 
sleep(lOOO) 
endlf 
endlf 

endmethod 
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method  pushButton(var  eventlnfo  Event) 

action(DataN  extRecord) 

endmethod 

method  pushButton(var  eventlnfo  Event) 

action(DataPriorRecord) 

endmethod 

method  pushButton(var  eventlnfo  Event) 

formRetum("OK") 

endmethod 
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APPENDIX  G:  APPLICATION  MENUS 


mmmmm 
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